DE102007004634A1

DE102007004634A1 - Verteilte Diagnosearchitektur

Info

Publication number: DE102007004634A1
Application number: DE102007004634A
Authority: DE
Inventors: Daniel P. Highland Grenn; Marek L. Pinckney Wilmanowicz; Aniket Southfield Kothari; Leonard G. Southfield Wozniak; Rick H. Lapeer Schroeder; Anrew M. Ann Arbor Zettel; Peter E. Brighton Wu; Wei d. Troy Wang; Michael J. Davison Taljonick; Jayanthi Troy Padmanabhan
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2006-01-30
Filing date: 2007-01-30
Publication date: 2007-09-27
Also published as: US8600605B2; US20070179691A1

Abstract

Eine verteilte fahrzeugeigene Diagnosearchitektur (OBD-Architektur) für ein Steuersystem eines Fahrzeugs umfasst mehrere Steuermodule, die miteinander in Verbindung stehen, und ein designiertes Master-OBD-Steuermodul, das eines der mehreren Steuermodule ist. Das Master-OBD-Steuermodul führt Funktionen aus, die ein Rest der mehreren Steuermodule nicht ausführen kann, umfassend ein Arbitrieren eines Störungsanzeigeleuchten-Zustands (MIL-Zustands) und/oder ein Arbitrieren und Speichern von OBD-Einzelbilddaten und/oder ein Ermitteln von OBD-Status-Flags des Rests der mehreren Steuermodule.

Description

QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
Diese Anmeldung beansprucht die Priorität der vorläufigen US-Anmeldung Nr. 60/763,483, die am 30. Januar 2006 eingereicht wurde.
GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft Fahrzeuge und insbesondere eine verteilte Diagnosearchitektur für ein Fahrzeug, das mehrere Steuermodule umfasst.

HINTERGRUND DER ERFINDUNG

Herkömmlich umfassen Fahrzeuge mehrere Systeme, die den gesamten Betrieb des Fahrzeugs regeln. Beispielsweise umfasst das Fahrzeug ein Antriebsaggregat (z.B. eine Brennkraftmaschine und/oder eine Elektromaschine), das ein Antriebsdrehmoment erzeugt, eine Energiespeichereinrichtung (z.B. Batteriepaket), die elektrische Energie bereitstellt, ein Getriebe, das das Antriebsdrehmoment auf die Antriebsräder verteilt, und verschiedene andere Systeme. Jedes der Systeme umfasst zugehörige Steuermodule oder Module, die untereinander kommunizieren, um den Betrieb des Fahrzeugs zu regeln.

Moderne Fahrzeuge umfassen ein fahrzeugeigenes Diagnosesystem (OBD-System von on-board diagnostic system), das nahezu die gesamte Maschinensteuerung bereitstellt und auch die Fahrzeugsysteme sowie das Diag nosesteuernetzwerk des Fahrzeugs überwacht. Das OBD-System prüft den korrekten Betrieb der verschiedenen Steuermodule der Fahrzeugsysteme sowie der Sensoren (z.B. Lambdasonden vor und nach dem Katalysator) und anderer Komponenten. Wenn bei irgendeiner der Komponenten ein Fehler auftritt, leuchtet eine Störungsanzeigeleuchte (MIL von malfunction indicator lamp) auf und wird ein Diagnosefehlercode (DTC von diagnostic trouble code) gesetzt. Ein Fahrzeugtechniker oder -besitzer kann durch verbinden eines generischen Wartungswerkzeugs mit einem sich an dem Fahrzeug befindenden OBD-Port, das den DTC ausliest, leicht die Quelle des Fehlers ermitteln.

Mit der Einführung von komplexeren Fahrzeugsystemen, wie beispielsweise Hybridelektrofahrzeugen, erhöht sich die Anzahl von miteinander verbundenen Steuermodulen. Als ein Ergebnis steigert sich die Koordination der durch die OBD erforderliche Diagnose der einzelnen Steuermodule. Demgemäß sind OBD-Systeme auf die einzigartigen Systeme eines bestimmten Fahrzeugs abgestimmt, was für jede Fahrzeugplattform Zeit, Aufwand und Kosten erfordert. Derzeit gibt es keinen Ansatz für ein allgemeines OBD-System, das leicht an ein Fahrzeug mit variierenden Systemkonfigurationen angepasst werden kann.

ZUSAMMENFASSUNG DER ERFINDUNG

Demgemäß stellt die vorliegende Erfindung eine verteilte fahrzeugeigene Diagnosearchitektur (OBD-Architektur) für ein Steuersystem eines Fahrzeugs bereit. Die verteilte OBD-Architektur umfasst mehrere Steuermodule, die miteinander in Verbindung stehen, und ein designiertes Master-OBD-Steuermodul, das eines der mehreren Steuermodule ist. Das Master-OBD-Steuermodul führt Funktionen aus, die ein Rest der mehreren Steuermodule nicht ausführen kann, umfassend ein Arbitrieren eines Stö rungsanzeigeleuchten-Zustands (MIL-Zustands) und/oder ein Arbitrieren und Speichern von OBD-Einzelbilddaten und/oder ein Ermitteln von OBD-Status-Flags des Rests der mehreren Steuermodule.

Bei einer Ausführungsform führt jedes der mehreren Steuermodule einen OBD-Algorithmus aus, um zu überwachen, ob ein Eingang und/oder ein Ausgang und/oder ein System, der bzw. das zu einem bestimmten Steuermodul gehört, korrekt funktionieren bzw. funktioniert.

Bei anderen Ausführungsformen führt jedes der mehreren Steuermodule eine Selbstdiagnose aus. Die Selbstdiagnose umfasst eine Prüfung von ROM und/oder RAM und/oder anderen Speichereinrichtungen und/oder allen anderen mit Emissionen in Verbindung stehenden Peripherieeinrichtungen in dem bestimmten Steuermodul.

Bei einer anderen Ausführungsform inkrementiert jedes der mehreren Steuermodule eine ratenbasierte Diagnoseüberwachung, wenn ihm eine zugeordnet ist.

Bei einer anderen Ausführungsform umfasst die verteilte OBD-Architektur ferner ein designiertes primäres OBD-Steuermodul, das eines der mehreren Steuermodule ist. Das Master-OBD-Steuermodul und das primäre OBD-Steuermodul speichern mindestens einen Diagnosefehlercode (DTC), der einem des Rests der mehreren Steuermodule entspricht, das zu dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul gehört, und speichern ihre eigenen DTCs.

Bei einer anderen Ausführungsform umfasst die verteilte OBD-Architektur ferner ein designiertes primäres OBD-Steuermodul, das eines der mehreren Steuermodule ist. Das Master-OBD-Steuermodul und das primäre OBD-Steuermodul speichern mindestens einen ratenbasierten Überwachungswert, der einem des Rests der mehreren Steuermodule entspricht, das zu dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul gehört, und speichern ihre eigenen ratenbasierten Überwachungswerte.

Bei einer anderen Ausführungsform umfasst die verteilte OBD-Architektur ferner ein designiertes primäres OBD-Steuermodul, das eines der mehreren Steuermodule ist. Das Master-OBD-Steuermodul und das primäre Steuermodul können über ein Gateway OBD-Signale zwischen einem ersten Kommunikationsbus und einem zweiten Kommunikationsbus liefern.

Bei einer anderen Ausführungsform umfasst die verteilte OBD-Architektur ferner ein designiertes primäres OBD-Steuermodul, das eines der mehreren Steuermodule ist. Das Master-OBD-Steuermodul und das primäre Steuermodul speichern und berichten eine Kalibrierungsidentifikations- und eine Kalibrierungsverifikationszahlinformation von mindestens einem des Rests der mehreren Steuermodule, das zu dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul gehört.

Bei einer anderen Ausführungsform umfasst die verteilte OBD-Architektur ferner ein designiertes primäres OBD-Steuermodul, das eines der mehreren Steuermodule ist. Das primäre OBD-Steuermodul liefert dem Master-OBD-Steuermodul Signale, die ein mit Emissionen in Verbindung stehendes DTC-Signal und/oder ein mit Emissionen in Verbindung stehendes Störungsaktivsignal umfassen.

Bei noch anderen Ausführungsformen umfasst die verteilte OBD-Architektur ferner ein designiertes primäres OBD-Steuermodul und ein desig niertes sekundäres Steuermodul der mehreren Steuermodule. Das sekundäre Steuermodul liefert dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul eine zugehörige ratenbasierte Überwachungsinformation. Die verteilte OBD-Architektur umfasst ferner ein designiertes abhängiges sekundäres OBD-Steuermodul der mehreren Steuermodule, das ein Löschen einer Diagnoseinformation auf der Grundlage von lediglich einer Anweisung von dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul und/oder ein Liefern einer Kalibrierungsidentifikations- und einer Kalibrierungsverifikationszahlinformation an ein zugehöriges Host-Steuermodul ausführt.

KURZBESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung wird aus der detaillierten Beschreibung und den begleitenden Zeichnungen deutlicher verständlich, in denen:
1 ein funktionales Blockdiagramm eines beispielhaften Fahrzeugsystems ist, das eine verteilte Diagnosearchitektur gemäß der vorliegenden Erfindung umfasst;
2 ein funktionales Blockdiagramm der verteilten Diagnosearchitektur der vorliegenden Erfindung einschließlich mehrerer beispielhafter Steuermodule ist.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Die folgende Beschreibung der bevorzugten Ausführungsform ist lediglich beispielhafter Natur und beabsichtigt auf keine Weise, die Erfindung, ihre Anwendung oder Verwendungen zu beschränken. Zu Klarheitszwecken werden die gleichen Bezugszeichen in den Zeichnungen verwendet, um ähnliche Elemente zu identifizieren. Wie hierin verwendet bezieht sich der Ausdruck Modul auf einen anwendungsspezifischen Schaltkreis (ASIC), einen elektronischen Schaltkreis, einen Prozessor (gemeinsam genutzt, zugeordnet oder gruppiert) und einen Speicher, die ein oder mehrere Software- oder Firmwareprogramme ausführen, einen Schaltkreis mit kombinatorischer Logik und/oder andere geeignete Bauteile, die die beschriebene Funktionalität bereitstellen. Wie hierin verwendet bezieht sich der Ausdruck Standard-Fahrzyklus einer fahrzeugeigenen Diagnose (OBD) auf einen Fahrzyklus, während dem Diagnosen an allen Systemen des Fahrzeugs ausgeführt werden.
Bezug nehmend auf 1 umfasst ein beispielhaftes Hybridfahrzeug 10 eine Maschine 12 und eine Elektromaschine 14, die ein Getriebe 16 antreiben. Genauer gesagt ergänzt die Elektromaschine 14 die Maschine 12, um ein Antriebsdrehmoment zu erzeugen, um das Getriebe 16 anzutreiben. Auf diese Weise wird eine Kraftstoffwirtschaftlichkeit erhöht und werden Emissionen reduziert. Die Maschine 12 und die Elektromaschine 14 sind über ein Riemen-Lichtmaschine-Anlasser-System (BAS-System von belt-alternator-starter system) 18 gekoppelt. Genauer gesagt dient die Elektromaschine 14 als ein Anlasser (d.h. Motor) und eine Lichtmaschine (d.h. Generator) und ist mit der Maschine 12 über ein Riemen- und Riemenscheibensystem gekoppelt. Die Maschine 12 und die Elektromaschine 14 umfassen Riemenscheiben 20 bzw. 22, die für eine Drehung durch einen Riemen 24 gekoppelt sind. Die Riemenscheibe 20 ist für eine Drehung mit einer Kurbelwelle 26 der Maschine 12 gekoppelt.
In einem Modus treibt die Maschine 12 die Elektromaschine 14 an, um Energie zu erzeugen, die verwendet wird, um eine Energiespeichereinrichtung (ESD) 28 neu zu laden. In einem anderen Modus treibt die Elektro maschine 14 die Maschine 12 unter Verwendung von Energie von der ESD 28 an. Die ESD 28 kann eine Batterie und/oder einen Superkondensator umfassen, ist jedoch nicht darauf beschränkt. Alternativ kann das BAS-System 18 durch ein Schwungrad-Lichtmaschine-Anlasser-System (FAS-System von flywheel-alternator-starter system) (nicht gezeigt) ersetzt sein, das eine Elektromaschine umfasst, die betätigbar zwischen der Maschine und dem Getriebe oder einer Kette oder einem Zahnradsystem angeordnet ist, das bzw. die zwischen der Elektromaschine 14 und der Kurbelwelle 26 realisiert ist.
Obwohl das Getriebe als ein stufenloses Getriebe (CVT) gezeigt ist, kann das Getriebe 16 ein CVT, ein manuelles Getriebe, ein Automatikgetriebe und ein automatisiertes manuelles Getriebe (AMT) umfassen, ist jedoch nicht darauf beschränkt. Ein Antriebsdrehmoment wird von der Maschinenkurbelwelle 26 über eine Koppeleinrichtung 30 an das Getriebe 16 übertragen. Die Koppeleinrichtung 30 kann in Abhängigkeit von dem Typ des realisierten Getriebes eine Reibungskupplung oder einen Drehmomentwandler umfassen, ist aber nicht darauf beschränkt. In dem Fall eines CVT ist die Koppeleinrichtung 30 ein Drehmomentwandler, der eine Drehmomentwandlerkupplung (TCC) 31 umfasst. Das Getriebe 16 vervielfacht das Antriebsdrehmoment über eines mehrerer Übersetzungsverhältnisse, um eine Antriebswelle 32 anzutreiben.
Ein Steuersystem 34 regelt den Betrieb des Fahrzeugs 10 und ist gemäß der verteilten Diagnosearchitektur der vorliegenden Erfindung ausgestaltet. Genauer gesagt umfasst das Steuersystem 34 mehrere Steuermodule, die zu verschiedenen Komponenten des Fahrzeugs 10 gehören und die über mindestens einen Controller Area Network-Bus (CAN-Bus) kommunizieren, wie nachstehend ausführlicher erklärt. Das Steuersystem 34 umfasst mindestens vier Designationen von Steuermodulen einer fahrzeugei genen Diagnose (OBD), die umfassen: ein Master-OBD-Steuermodul, ein primäres OBD-Steuermodul, ein sekundäres OBD-Steuermodul und ein abhängiges sekundäres OBD-Steuermodul. Genauer gesagt umfasst das Steuersystem 34 ein Master-OBD-Steuermodul, Null oder mehrere primäre OBD-Steuermodule, Null oder mehrere sekundäre OBD-Steuermodule und Null oder mehrere abhängige sekundäre OBD-Steuermodule. Die Verantwortungen und/oder Anforderungen jedes Typs von OBD-Steuermodul werden nachstehend ausführlicher erläutert. Im Allgemeinen überwacht das Steuersystem 34 Komponenten und Systeme, speichert das Steuersystem 34 Diagnosefehlercode-(DTC-)BESTANDEN/VERSAGT-Entscheidungen, hält das Steuersystem 34 im Betrieb befindliche Leistungsverhältnisse aufrecht, arbitriert das Steuersystem 34 eine Störungsanzeigeleuchte (ML) und spricht das Steuersystem 34 auf Anfragen serieller Daten eines Diagnosetestmodus eines generischen Abtastwerkzeugs an.
Bezug nehmend auf 2 umfasst das beispielhafte Steuersystem 34 ein Master-OBD-Steuermodul 40, erste, zweite und dritte primäre OBD-Steuermodule 42, 44, 46, erste und zweite sekundäre OBD-Steuermodule 48, 50, erste und zweite abhängige sekundäre OBD-Steuermodule 52, 54 und erste bis vierte allgemeine Steuermodule 56, 58, 60, 62. Obwohl die allgemeinen Steuermodule 56, 58, 60, 62 mit anderen Steuermodulen kommunizieren, um den Betrieb ihrer jeweiligen Systeme zu regeln, sind die allgemeinen Steuermodule 56, 58, 60, 62 keine OBD-Steuermodule und für einen korrekten Betrieb der verteilten OBD-Architektur nicht erforderlich.
Bei einer beispielhaften Ausführungsform ist das Master-OBD-Steuermodul 40 ein Maschinensteuermodul (ECM), das den Gesamtbetrieb der Maschine 12 regelt. Die ersten, zweiten und dritten primären OBD-Steuer module 42, 44, 46 umfassen ein Getriebesteuermodul (TCM), ein Kraftstoffsystemsteuermodul (FSCM) und einen Hybridsteuerprozessor (HCP). Die ersten und zweiten sekundären OBD-Steuermodule 48, 50 umfassen ein Batteriepaketsteuermodul (BPCM) und ein Steuermodul einer elektronischen Bremse (EBCM). Die ersten und zweiten abhängigen sekundären Steuermodule 52, 54 umfassen Motorsteuerprozessoren A und B (MCPA, MCPB). Ein Traktionsleistungsinvertermodul (TPIM) umfasst den HCP, den MCPA und den MCPB. Die ersten bis vierten allgemeinen Steuermodule 56, 58, 60, 62 können ein Karosseriesteuermodul (BCM), ein Verteilergetriebesteuermodul (TCCM), ein Steuermodul einer elektronischen Servolenkung (EPS) bzw. ein Kommunikations-Gateway-Modul (CGM) umfassen, sind aber nicht darauf beschränkt. Die verschiedenen Module kommunizieren über erste und zweite CAN-Busse 64, 66. Demgemäß sind die Steuermodule jene, die normalerweise zu einem bestimmten System gehören, umfassen jedoch auch OBD-Funktionen auf der Grundlage der verteilten Diagnosearchitektur der vorliegenden Erfindung.
Die Verantwortungen und/oder Anforderungen der verschiedenen OBD-Steuermodule des Steuersystems 34 umfassen die Folgenden, die mit jeweiligen Identifikatoren A–Q versehenen sind, sind jedoch nicht darauf beschränkt:

A: – Diagnostiziere zugehörige Komponenten und Systeme
B: – Speichere eigene DTCs
C: – Arbitriere einen Störungsanzeigeleuchten-Zustand (MIL-Zustand)
D: – Liefere eine Fehlerstatusinformation an zugehöriges Host-Steuermodul
E: – Speichere eine DTC-Information von zugehörigen sekundären und/oder abhängigen sekundären Steuermodulen
F: – Inkrementiere Zähler und Nenner für zugehörige ratenbasierte Überwachungen
G: – Speichere Zähler und Nenner für jegliche ratenbasierten Überwachungen, die berichtet werden
H: – Liefere ratenbasierten Überwachungsstatus an zugehöriges Host-Steuermodul
I: – Arbitriere und speichere das durch die OBD erforderliche Einzelbild
J: – Ermittle und liefere OBD-Status-Flags an andere Steuermodule
K: – Liefere über ein Gateway einen Aufwärmzyklusstandardzustand, Kaltstartzustände und eine Diagnoseinformationslöschung an abhängige sekundäre Steuermodule
L: – Lösche Diagnoseinformation auf der Grundlage von lediglich einer Anweisung von Master- oder primärem Steuermodul
M: – Liefere Unterstützung für Diagnosetestmodi eines generischen Abtastwerkzeugs
N: – Liefere Kalibrierungsidentifikations- und Kalibrierungsverifikationszahlinformation an zugehöriges Host-Steuermodul
O: – Speichere und berichte Kalibrierungsidentifikations- und Kalibrierungsverifikationszahlinformation für zugehörige abhängige sekundäre Steuermodule
P: – Liefere dem Master-Steuermodul die Signale: mit Emissionen in Verbindung stehender DTC; und mit Emissionen in Verbindung stehende Störung aktiv
Q: – Umfasse nichtflüchtigen Speicher (NVM), um Fehlerstatusinformation und Statusinformation von ratenbasierter Überwachung zu speichern, um sie dem nächsten Zündzyklus zu berichten.

Die folgende Tabelle erläutert auf der Grundlage der zugehörigen Identifikatoren, welche der oben beschriebenen Verantwortungen/Anforderungen zu welchem Steuermodul gehören:
Tabelle 1
Nachstehend werden alle Verantwortungen und Anforderungen erläutert.
Verantwortung/Anforderung A:
Jedes Steuermodul umfasst Diagnoseüberwachungen, von denen jede ein fahrzeugeigener Diagnosetest ist, der das Befinden eines Eingangs, eines Ausgangs und/oder eines Systems überwacht. Der Diagnosealgorithmus definiert kalibrierbare Zustände, während denen der Eingang, der Ausgang und/oder das System als fehlerhaft betrachtet wird, sowie Zustände, bei denen der Eingang, der Ausgang und/oder das System als korrekt funktionierend betrachtet werden. Jedes Steuermodul muss sich selbst diagnostizieren, was eine Prüfung von ROM, RAM und anderen primären Speichereinrichtungen umfasst, aber nicht darauf beschränkt ist. Diese Selbstdiagnose umfasst auch eine Prüfung aller anderen mit Emissionen in Verbindung stehenden Peripherieeinrichtungen in dem Steuermodul, wenn ermittelt wird, dass keine andere durch die OBD erforderliche Überwachung solche Fehler in diesen Steuermodulen detektiert. Zusätzlich muss jedes Steuermodul alle Eingänge und Ausgänge diagnostizieren, die während jedes sinnvollen im Betrieb befindlichen Fahrzustands Emissionen beeinflussen können, oder die als Teil der Diagnosestrategie für eine beliebige andere Diagnoseüberwachung verwendet werden. Es kann auch ein Steuermodul zugeordnet sein, um Hauptsysteme und -signale zu diagnostizieren (z.B. Katalysatorüberwachung).
Verantwortung/Anforderung B:
Ein Steuermodul, das seine eigenen DTCs speichert, enthält die Algorithmen, die notwendig sind, um die DTCs zu speichern und sie in einem standardisierten Format über einen standardisierten Diagnose-Link an ein Abtastwerkzeug zu berichten. Dies erfordert eine residente Diagnosedatenverwaltungssoftware, die verantwortlich dafür ist, für jede Diagnoseüberwachung BESTANDEN- und VERSAGT-Berichte aufzuzeichnen.
Verantwortung/Anforderung C:
Das Master-OBD-Steuermodul befiehlt MIL AN, wenn entweder das Master-OBD-Steuermodul selbst einen aktiven mit Emissionen in Verbindung stehenden DTC aufweist, oder wenn das Master-OBD-Steuermodul ein mit Emissionen in Verbindung stehendes Störungsaktivsignal mit einem Wert WAHR von einem primären OBD-Steuermodul empfängt. Die mit Emissionen in Verbindung stehenden Störungsaktivsignale umfassen ein mit Hybridsystememissionen in Verbindung stehendes Störungsaktivsignal, ein mit Getriebeemissionen in Verbindung stehendes Störungsaktivsignal und ein mit Kraftstoffsystememissionen in Verbindung stehendes Störungsaktivsignal, sind jedoch nicht darauf beschränkt.
Ein MIL-Anfragebefehl einer höheren Priorität hat Vorrang vor dem OBD-Befehl. Einige Beispiele von MIL-Befehlen höherer Priorität umfassen eine Fehlzündungsdiagnoseanfrage, um die MIL aufgrund einer den Katalysator beschädigenden Fehlzündung mit 1 Hz aufblinken zu lassen, eine ECM-Anfrage für ein Aufleuchten der MIL und/oder eine Kraftstoffpumpenprimärlogik, die anfragt, um die MIL aufblinken zu lassen, sind jedoch nicht darauf beschränkt. Wenn das Master-OBD-Steuermodul ein mit Emissionen in Verbindung stehendes Störungsaktivsignal mit dem Wert FALSCH empfängt, wird der MIL ein AUS befohlen, wenn keine Anfrage AN für die MIL vorliegt oder die MIL aus einem beliebigen anderen Grund blinkt. Das Master-OBD-Steuermodul sendet eine mit Maschinenemissionen in Verbindung stehende Störungsanzeigeanfrage für den momentan befohlenen MIL-Zustand.
Der Zustand (d.h. WAHR oder FALSCH) des mit Emissionen in Verbindung stehenden Störungsaktivsignals hat keinen Einfluss auf den Zustand des Master-OBD-Steuermodul-MIL-Status. Der Master-OBD-Steuermodul-MIL-Status ist eine Funktion von in dem Master-OBD-Steuermodul gespeicherten DTCs und hängt von dem generischen Fehler-DTC eines primären OBD-Steuermoduls oder einem mit Emissionen in Verbindung stehenden Störungsaktivsignals eines primären OBD-Steuermoduls ab. Das Master-OBD-Steuermodul sendet das mit Maschinen emissionen in Verbindung stehende Störungsaktivsignal als eine Anzeige eines Aktivseins eines mit Maschinenemissionen in Verbindung stehenden DTC.
Verantwortung/Anforderung D:
Die sekundären und abhängigen sekundären OBD-Steuermodule senden für die Signalbeschreibung Diagnosestatussignale an ihr zugehöriges primäres oder Master-OBD-Steuermodul. Diese Signale umfassen den Status von Speicherdiagnosen (z.B. RAM, ROM, etc.), sind jedoch nicht darauf beschränkt.
Verantwortung/Anforderung E:
Die Master- und die primären OBD-Steuermodule speichern eine DTC-Information für die sekundären und abhängigen sekundären OBD-Steuermodule. Die DTC-Information wird für den Signalbeschreibungsdiagnosestatus gespeichert. Die empfangene DTC-Information wird für eine Speicherung in dem zündungsunabhängigen oder batterieunabhängigen NVM an die Diagnosedatenverwaltungseinrichtung berichtet.
Verantwortung/Anforderung F:
Jede ratenbasierte Diagnoseüberwachung ist dafür verantwortlich, unabhängig zu ermitteln, wann ihr Zähler und Nenner inkrementiert werden sollen. Die durch jede Überwachung zum Beeinflussen der Entscheidungen, Zähler und Nenner zu inkrementieren, verwendeten Signale umfassen Fehler einer vorgegebenen Diagnose bei Kaltstartzuständen vorhanden, Kaltstartzustände einer vorgegebene Diagnose erfüllt, Standardzustände einer vorgegebene Diagnose zurückgesetzt, Fehler einer vorgegebenen Diagnose bei Standardzuständen vorhanden und Standardzustände einer vorgegebenen Diagnose erfüllt, sind jedoch nicht darauf beschränkt.
Verantwortung/Anforderung G:
Die Master- und die primären OBD-Steuermodule speichern eine ratenbasierte Überwachungsinformation für die sekundären und abhängigen sekundären OBD-Steuermodule. Die ratenbasierten Überwachungszähler und -nenner werden für die Signalbeschreibung für den ratenbasierten Überwachungsstatus aktualisiert.
Verantwortung/Anforderung H:
Jedes sekundäre und abhängige sekundäre OBD-Steuermodul mit ratenbasierten Überwachungen überträgt den ratenbasierten Überwachungsstatus für die Signalbeschreibung, wie nachstehend ausführlich erläutert.
Verantwortung/Anforderung I:
Das Master-OBD-Steuermodul empfängt den mit Emissionen in Verbindung stehenden DTC und die mit Emissionen in Verbindung stehenden Störungsaktivsignale als die Eingabe für einen generischen Fehler-DTC. Die generischen Fehler-DTCs umfassen ein durch ein Getriebesteuermodul (TCM) angefragtes Aufleuchten einer MIL, ein durch einen Hybridsteuerprozessor (HCP) angefragtes Aufleuchten einer MIL und ein durch ein Kraftstoffsystemsteuermodul (FSCM) angefragtes Aufleuchten einer MIL, sind jedoch nicht darauf beschränkt. Das Master-OBD-Steuermodul ermittelt, wann ein VERSAGT und/oder ein BESTANDEN für den speziellen generischen Fehler-DTC unter Verwendung des mit Emissionen in Verbindung stehenden DTC und der mit Emissionen in Verbindung stehenden Störungsaktivsignale berichtet werden soll.
Die Kriterien für die Überwachung des generischen Fehler-DTC basieren lediglich auf den Werten des mit Emissionen in Verbindung stehenden DTC und der mit Emissionen in Verbindung stehenden Störungsaktivsignale. Die Versagenskriterien sind die Detektion eines DTC von nicht Null in dem mit Emissionen in Verbindung stehenden DTC und ein wahrer Wert bei den mit Emissionen in Verbindung stehenden Störungsaktiv. Ein Versagen für den generischen Fehler-DTC wird einmal pro Zündzyklus unter der Voraussetzung berichtet, dass die Codes nicht gelöscht werden. Ein BESTANDEN für den generischen DTC wird einmal pro Zündzyklus unter der Voraussetzung berichtet, dass die Codes nicht gelöscht werden. Ein generischer Fehler-DTC versagt und wird gespeichert, wenn sich der Wert des mit Emissionen in Verbindung stehenden DTC oder der mit Emissionen in Verbindung stehenden Störungsaktiv ändert, so dass der mit Emissionen in Verbindung stehende DTC nicht Null ist und die mit Emissionen in Verbindung stehenden Störungsaktiv WAHR sind. Ein Bestehen wird berichtet, wenn der mit Emissionen in Verbindung stehende DTC Null ist und die mit Emissionen in Verbindung stehenden Störungsaktiv FALSCH sind.
Das Master-OBD-Steuermodul verwendet das mit Emissionen in Verbindung stehende DTC-Signal, um den Wert des exakten DTC zu ermitteln, der in dem Einzelbild gespeichert werden soll, wenn die Zustände für seine Erfassung korrekt sind. Die Zustände zum Erfassen eines Einzelbilds (d.h. eines Bilds von Zuständen relevanter Daten, wenn ein DTC aktiviert ist) in dem Master-OBD-Steuermodul umfassen, dass das Einzelbild leer ist und ein generischer Fehler-DTC als ein bestätigter Code gespeichert wird, sind jedoch nicht darauf beschränkt. Der generische Fehler-DTC in dem Master-OBD-Steuermodul wird als eine Diagnose vom Typ A ohne Aufleuchtanfrage kalibriert, so dass der MIL nicht indirekt durch den generischen Fehler-DTC ein AN befohlen wird.
Verantwortung/Anforderung J:
Das Master-OBD-Steuermodul ist dafür verantwortlich, die folgenden Signale für die Signalbeschreibungen zu liefern:

– ein Maschinenaufwärmzyklus-erreicht-Signal, das durch die primären OBD-Steuermodule verwendet wird, um nach einer spezifizierten Anzahl von Aufwärmzyklen eine DTC-Verlaufsinformation von dem OBD-Speicher zu löschen;
– ein Diagnosekaltstartzustände-Fehlervorhandenseins-Signal, das der alternative Aufruf ist, um ein Inkrementieren von ratenbasierten Zählern für Überwachungen zu verhindern, die nur ausgeführt werden können, wenn das Fahrzeug einen Kaltstart erfährt;
– ein Diagnosekaltstartzustände-erfüllt-Signal, das der alternative Aufruf ist, um ratenbasierte Nenner für Überwachungen zu inkrementieren, die nur ausgeführt werden können, wenn das Fahrzeug einen Kaltstart erfährt;
– ein Diagnosestandardzustände-Fehlervorhandenseins-Signal, das ein Aufruf ist, um ein Inkrementieren von ratenbasierten Nennern zu verhindern, da die Standardzustände aufgrund eines Fehlers in dem OBD-System nicht erfüllt werden (dieses Signal wird nicht in Verbindung mit ratenbasierten Überwachungen verwendet, die nur ausgeführt werden können, wenn das Fahrzeug einen Kaltstart erfährt);
– ein Diagnosestandardzustände-erfüllt-Signal, das ein Aufruf ist, ratenbasierte Nenner zu inkrementieren (dieses Signal wird nicht in Verbindung mit ratenbasierten Überwachungen verwendet, die nur ausgeführt werden können, wenn das Fahrzeug einen Kaltstart erfährt);
– ein Diagnosestandardzustände-rücksetz-Signal, das angibt, dass ein OBD-Fahrzyklus begonnen hat; und
– ein Diagnoseinformationslösch-Signal, das durch die primären OBD-Steuermodule verwendet wird, um dieses Signal über ein Gateway zu abhängigen sekundären OBD-Steuermodulen zu liefern, wenn dies notwendig ist.

Die oben erläuterten Signale, die nachstehend ausführlicher erklärt werden, werden von allen OBD-Steuermodulen zum Zweck des Aufrechterhaltens des Zählers und Nenners bei im Betrieb befindlichen Verhältnissen verwendet, allgemein bezeichnet als ratenbasierte Überwachungen. Es sei auch angemerkt, dass ein Standard-OBD-Fahrzyklus an dem Low-High-Übergang der Lauf-/Kurbelfestverdrahtung beginnt und der vorherige Zyklus hier endet. Bei Steuersystemen, die keine Lauf-/Kurbelfestverdrahtung als Eingang aufweisen, wird das Diagnosestandardzuständerücksetz-Signal (z.B. Low-High-Übergang) verwendet, um den Beginn eines Standard-OBD-Fahrzyklus anzugeben.
Verantwortung/Anforderung K:
Es kann erforderlich sein, dass ein Steuermodul OBD-Systemsignale von dem Haupt-OBD-Bus zu einem anderen Kommunikationsbus über ein Gateway liefert. Zustände, die Gateway-Anforderungen ansteuern, sind anwendungsspezifisch und können eine serielle Datenarchitektur, OBD-Betrachtungen, Entwicklungsanforderungen und dergleichen umfassen. Wenn es erforderlich ist, dass ein Steuermodul OBD-Systemsignale über ein Gateway liefert, überträgt das Steuermodul die letzten empfangenen Werte mehrerer Statusindikatoren, die Maschinenaufwärmzyklus erreicht, Fehler einer vorgegebenen Diagnose bei Kaltstartzuständen vorhanden, Kaltstartzustände einer vorgegebenen Diagnose erfüllt, Fehler einer vorgegebenen Diagnose bei Standardzuständen vorhanden, Standardzustände einer vorgegebenen Diagnose erfüllt und Löschen einer Information einer vorgegebenen Diagnose umfassen, jedoch nicht darauf beschränkt sind. Diese Statusindikatoren werden von dem Haupt-OBD-Bus an den erforderlichen Kommunikationsbus übertragen. Wenn keine Daten von dem Haupt-OBD-Bus empfangen werden, werden die definierten Fail-Soft-Daten an dem Gateway-Bus übertragen. Jeder Kommunikations-Link, über den diese Signale über ein Gateway geliefert werden, muss als eine Komponente einer vorgegebenen Diagnose durch das Steuermodul (z.B. das Master- oder das primäre), das das Gateway bildet, diagnostiziert werden.
Verantwortung/Anforderung L:
Ein abhängiges sekundäres OBD-Steuermodul unterstützt den Lösch/Rücksetz-Modus für eine mit Emissionen in Verbindung stehende Diagnoseinformation (d.h. Modus $04) nicht direkt, sondern löscht alle Fehlerinformationen auf der Grundlage des Signals zum Löschen der Information der vorgegebenen Diagnose. Optional können spezifische Programme das Signal zum Löschen der Information der vorgegebenen Diagnose, wenn das abhängige sekundäre OBD-Steuermodul sich nicht an dem Haupt-OBD-Bus befindet, und/oder andere programmspezifische Anforderungen über ein Gateway liefern. Dies umfasst alle Fehlerdiagnosezählwerte und Fehlerstatus in seinem Speicher, ist jedoch nicht darauf beschränkt. Das Signal hat keinen Einfluss auf die ratenbasierten Überwachungszähler und -nenner.
Verantwortung/Anforderung M:
Alle Master-, primären und sekundären OBD-Steuermodule müssen auf die Diagnosetestmodi des generischen Abtastwerkzeugs ansprechen, wie durch die nachstehende Tabelle definiert. Ein abhängiges sekundäres OBD-Steuermodul spricht nicht direkt auf das Abtastwerkzeug an. Parameteridentifikationscodes (PIDs) müssen nur dann unterstützt werden, wenn sie in der Steuerung oder Diagnose des Emissionssteuersystems durch jedes Steuermodul in dem Steuersystem 34 verwendet werden.

Tabelle 2
Verantwortung/Anforderung N:
Ein abhängiges sekundäres OBD-Steuermodul muss eine Kalibrierungsidentifikations- und eine Kalibrierungsverifikationszahlinformation an sein zugehöriges Host-Steuermodul senden, so dass das Host-Steuermodul die Diagnoseanforderungen erfüllen kann. Alle in dem abhängigen sekundären OBD-Steuermodul gespeicherten Software- und Kalibrierungsdaten sind durch eine oder mehrere Kalibrierungsidentifikationszahlen (CIDs) und Kalibrierungsverifikationszahlen (CVNs) abgedeckt. Jede CID stellt einen Bereich des ROM dar und kann den gesamten oder einen Teil des ROM des Steuermoduls abdecken, überschneidet sich jedoch nicht Segmenten des ROM, die in anderen CIDs umfasst ist. Es gibt eine ausreichende Anzahl von CIDs, um den gesamten ROM zu umfassen. Ein abhängiges sekundäres OBD-Steuermodul weist nicht mehr als eine Schwellenwertanzahl von CIDs (z.B. 16) auf. Die CIDs sind vorzugsweise ASCII-Folgen mit 16 Stellen, wobei die vollständige ASCII-Zeichenfolge mit 16 Stellen in dem ROM als eine 16-Stellen-ASCII-Folge gespeichert ist.
Eine CID wird für jede Softwaresteuermodulteilenummer und Kalibrierungssteuermodulteilenummer unterstützt. Die Werte der CIDs sind gleich der Software- oder Kalibrierungsmodulteilenummern, die in ASCII dargestellt sind. Die CIDs werden in dem Steuermodul gespeichert und sind von jeglichen Herstellungsrückverfolgbarkeitsteilenummern separat. Nicht verwendete CID-Zeichen werden als $00 gespeichert und berichtet. Genauer gesagt ist die CID linksbündig und wird mit $00 aufgefüllt.
Jede CID umfasst eine entsprechende CVN, die die Prüfsummenberechnung für den Bereich des Speichers darstellt, der durch die CID identifiziert ist. Die CVN verwendet das Industriestandard-CRC-16-Verfahren, das das Polynom x^16 + x^15 + x^2 + 1 implementiert, um ein 16-Bit-Ergebnis bereitzustellen. Byte 1 ist das höchstwertigste Byte der CVN, wenn jedoch weniger als 4 Byte verwendet werden, ist die CVN rechtsbündig und wird mit $00 aufgefüllt. Dies impliziert, dass Byte 1 und Byte 2 mit $00 aufgefüllt werden. Jegliche nicht programmierten oder nicht verwendeten Abschnitte des ROM, die Teil des Bereichs sind, von dem eine Prüfsumme gebildet wird, müssen nicht in die CVN-Berechnung aufgenommen werden. Die CVN-Berechnung wird unter der Voraussetzung, dass der Zündzyklus größer ist als eine Schwellenwertzeitdauer (z.B. 2 Minuten), einmal in jedem Zündzyklus ausgeführt. Für CIDs, die eine Kalibrierung/Software darstellen, welche nicht neuprogrammierbar ist, wird die entsprechende CVN auf Null gesetzt oder kann das Ergebnis einer Berechnung sein, wenn dies erwünscht ist.
Ein abhängiges sekundäres OBD-Steuermodul verwendet sein Kalibrierungsidentifikationsinformationssignal, um seine CIDs und CVNs an seinen Host-Controller zu übertragen.
Verantwortung/Anforderung O:
Ein dem abhängigen sekundären OBD-Steuermodul zugehöriges Hoststeuermodul speichert und berichtet die CID- und die CVN-Information für sein abhängiges sekundäres OBD-Steuermodul, so dass es Fahrzeuginformationsanfrage-Diagnoseanforderungen (d.h. Modus $09) erfüllt. Das Host-Steuermodul empfängt Kalibrierungsidentifikationsinformationssignale von seinen abhängigen sekundären OBD-Steuermodulen und stellt entweder einen zündungsunabhängigen oder einen batterieunabhängigen Speicher (z.B. 20 Byte) für eine Speicherung jeder empfangenen CID und CVN bereit. Das Host-Steuermodul stellt auch einen Speicher des gleichen Typs bereit, um den Speicherstatus jeder CID und CVN zu speichern, um zwischen Kalibrierungsidentifikationsindizes, die nicht verwendet werden, die Teilenummern aufweisen, die nicht empfangen wurden, die unberechnete CVNs aufweisen oder Teilenummern und CVNs aufweisen, die empfangen und gespeichert wurden, zu unterscheiden.
Das Host-Steuermodul speichert die letzten empfangenen CIDs und die zugehörigen berechneten CVNs und den Empfangsstatus jedes Kalibrierungsidentifikationsindex. Wenn eine neue CID mit einem Datenstatus empfangen wird, der angibt, dass die CVN nicht berechnet ist, wird sie gespeichert und als eine CID mit einer nicht berechneten CVN markiert, bis eine berechnete CVN empfangen wird. Diese Daten werden mit den eigenen Daten der Fahrzeuginformationsanfrage (d.h. Modus $09) des Host-Steuermoduls berichtet, wenn eine Fahrzeuginformationsanfrageantwort geliefert wird. Die Kalibrierungsidentifikationsindizes, die nicht verwendet werden, sind nicht in den berichteten Fahrzeuginformationsanfragedaten umfasst.
Verantwortung/Anforderung P:
Alle primären OBD-Steuermodule übertragen den mit Emissionen in Verbindung stehenden DTC und die mit Emissionen in Verbindung stehenden Störungsaktivsignale an das Master-OBD-Steuermodul, um die MIL geeignet aufleuchten zu lassen und Einzelbilddaten aufzuzeichnen.
Verantwortung/Anforderung Q:
Diese Verantwortung bezieht sich auf die sekundären und abhängigen sekundären OBD-Steuermodule, die einen zündungsunabhängigen oder batterieunabhängigen NVM für andere Zwecke enthalten können oder nicht enthalten können. In einigen Fällen werden BESTANDEN/VERSAGT-Entscheidungen für berichtete DTCs oder Entscheidungen zum Inkrementieren des ratenbasierten Zählers/Nenners erst getroffen, wenn eine normale serielle Datenkommunikation nach einem Abschalten beendet wurde. In diesen Fällen erfordert das betroffene sekundäre oder abhängige sekundäre OBD-Steuermodul, dass der NVM einen DTC-Fehler und/oder eine Statusinformation einer ratenbasierten Überwachung speichert und an den nächsten Zündzyklus berichtet (siehe Verantwortung/Anforderung D und H).
Die verschiedenen OBD-Signale, die durch die verteilte Diagnosestruktur der vorliegenden Erfindung realisiert sind, werden nun ausführlich erläutert. Das Master-OBD-Steuermodul ermittelt basierend auf dem High-Low-Übergang eines Kurbel-/Laufrelais (d.h. Maschinenstart), wann der Standard-OBD-Fahrzyklus beginnt. Das Master-OBD-Steuermodul setzt das Diagnosestandardzustände-rücksetz-Signal (DSCR-Signal) zu Beginn jedes Standard-OBD-Fahrzyklus für eine Schwellenwertzeitdauer (z.B. 1 Sekunde) auf WAHR. Auf diese Weise wird der Beginn des Standard-OBD-Fahrzyklus zwischen den verschiedenen verteilten OBD-Steuermodulen synchronisiert. Nach dem Ablauf der Schwellenwertzeitdauer wird das DSCR-Signal auf FALSCH geschaltet, und das Master-OBD-Steuermodul ist bereit, um eine ratenbasierte Überwachungsinformation von den anderen verteilten OBD-Steuermodulen zu empfangen. Das Master-OBD-Steuermodul ignoriert jegliche empfangene Information, wenn das DSR-Signal WAHR ist.
Für den ratenbasierten Überwachungsstatus eines bestimmten Steuermoduls und/oder -systems werden im Betrieb befindliche Verhältnisse, die aus Zählern und Nennern bestehen, aufrechterhalten. Die Verhältnisse werden durch asynchrones Inkrementieren des Zählers und des Nenners eines bestimmten Verhältnisses aufrechterhalten. Die Zähler werden mit dem Abschluss der OBD-Überwachung inkrementiert, und die Nenner werden auf der Grundlage von Standardfahrzuständen inkrementiert, die eine gültige Fahrt definieren.
Die sekundären und abhängigen sekundären OBD-Steuermodule übertragen das Paketsignal des Status der ratenbasierten Überwachung (RBMS-Paketsignal) für ein jeweiliges Modul und/oder System an die Master- und/oder die primären OBD-Steuermodule. Das RBMS-Paketsignal berichtet den Status aller ratenbasierten Überwachungen, die an dem bestimmten sekundären und/oder abhängigen sekundären OBD-Steuermodul laufen, durch periodisches zyklisches Durchlaufen jeder ratenbasierten Überwachung mit jedem Sukzessiven in aufeinander folgenden Übertragungen des RBMS-Paketsignals. Wenn z.B. das bestimmte sekundäre oder das abhängige sekundäre OBD-Steuermodul tatsächlich nur eine Teilmenge der maximalen Anzahl von ratenbasierten Überwachungen (z.B. 32) unterstützt, dann werden Pakete für alle nicht unterstützten Überwachungen mit einem Status gesendet, der KEINE HANDLUNG angibt. Nach einem Übertragen des letzten RBMS-Paketsignals startet der Prozess von neuem durch Senden eines Frames für die erste ratenbasierte Überwachung. Der primäre Zweck des RMBS-Paketsignals ist, eine ratenbasierte Zähler- und Nenneraufrechterhaltung in den Master- und/oder den primären OBD-Steuermodulen zu ermöglichen, ohne zu erfordern, dass die sekundären und/oder abhängigen sekundä ren OBD-Steuermodule die Last einer ratenbasierten Infrastruktursoftware und eines NVM tragen müssen.
Der berichtete ratenbasierte Überwachungsindex und der zugehörige Status werden mit einer periodischen Übertragungsrate inkrementiert oder aktualisiert, werden jedoch nicht schneller als mit der periodischen Übertragungsrate inkrementiert oder aktualisiert, so dass kein ratenbasierter Überwachungsindexwert und kein zugehöriger Status verloren geht. Wenn durch das Master- und/oder das primäre OBD-Steuermodul empfangene aufeinander folgende RBMS-Paketsignale identisch sind (z.B. der ratenbasierte Überwachungsindex und Status sind die gleichen wie die des letzten empfangenen Signals), ignoriert das Master- und/oder das primäre OBD-Steuermodul die zweite und jede weitere nachfolgende identische Nachricht. Dieser generische Mechanismus ermöglicht, den Mechanismus einer allgemeinen Schnittstelle konstant zu halten, sogar, wenn sich die Diagnoseanforderungen des sekundären und/oder des abhängigen sekundären OBD-Steuermoduls ändern.
Wie oben erwähnt umfasst das RBMS-Paketsignal den ratenbasierten Überwachungsindex (RBMI) und den ratenbasierten Überwachungsstatus (RBMS). Der RBMI wird als ein Index für eine Tabelle von unterstützten ratenbasierten Überwachungen verwendet und gibt die bestimmte Überwachung an, deren Status durch den RBMS angegeben ist. Der RBMS umfasst die ratenbasierten Zähler- und Nennerinkrementierungsentscheidungen für die durch den RBMI angegebene Überwachung.
Zu Beginn jedes Standard-OBD-Fahrzyklus wird der RBMS für jede Überwachung mit keine Handlung initialisiert. Der Zähler wird nicht inkrementiert, bevor ausreichend Zeit vergangen ist, dass eine VERSAGT-Entscheidung getroffen worden sein könnte. Wenn z.B. die Überwachung ermittelt, dass ein jeweiliger Test bestanden wurde, und die Zeitdauer, die erforderlich ist, um zu dieser Entscheidung zu gelangen, kleiner ist als die Zeitdauer, die erforderlich ist, um zu einer VERSAGT-Entscheidung zu gelangen, dann ist kein Inkrementieren des Zählers erlaubt, bevor eine ausreichende Zeitdauer für die VERSAGT-Entscheidung vergangen ist. Das sekundäre und/oder das abhängige sekundäre OBD-Steuermodul inkrementiert den ratenbasierten überwachungszähler nicht, während das Diagnosestandardzustände-Fehlervorhandenseins-Signal (DSCFP-Signal) WAHR ist. Das sekundäre und/oder das abhängige sekundäre OBD-Steuermodul inkrementiert einen ratenbasierten Überwachungszähler bei einem Kaltstart nicht, während das Diagnosekaltstartzustände-Fehlervorhandenseins-Signal (DCSCFP-Signal) WAHR ist. Sobald ein Inkrementiere Zähler-Status gesetzt wurde, ist der einzige andere gültige Status für den Rest des Standard-OBD-Fahrzyklus Inkrementiere Beide. Der Status kehrt weder zu KEINE HANDLUNG zurück, noch kann er auf Inkrementiere Nenner gesetzt werden. Wenn die Zustände, um die Status Inkrementiere Zähler und Inkrementiere Nenner zu setzen, gleichzeitig erfüllt werden, dann wird der Status auf Inkrementiere Beide gesetzt.
Das sekundäre und/oder das abhängige sekundäre OBD-Steuermodul kann den ratenbasierten Überwachungsnenner inkrementieren, wenn es ein Diagnosestandardzustände-erfüllt-Signal (DSCM-Signal) mit einem Wert von WAHR empfangen hat. Das sekundäre und/oder das abhängige sekundäre OBD-Steuermodul kann den ratenbasierten Überwachungsnenner beim Kaltstart inkrementieren, wenn es ein Diagnosekaltstartzustände-erfüllt-Signal (DCSCM-Signal) mit einem Wert von WAHR empfangen hat. Eine ratenbasierte Überwachung inkrementiert den Nenner nicht, wenn sie durch einen mit Emissionen in Verbindung stehenden DTC deaktiviert wird.
Die Entscheidungen, den Zähler und Nenner zu inkrementieren, sind asynchron und basieren auf eindeutig verschiedenen Zuständen. Die Folge von Ereignissen variiert mit jedem Standard-OBD-Fahrzyklus. Demgemäß wird erwartet, dass eine ratenbasierte Überwachung die möglichen Statuswerte von keiner Handlung bis zu entweder Inkrementiere Zähler oder Inkrementiere Nenner oder Inkrementiere Beide durchläuft.
Wie oben erläutert empfängt das zugehörige Master- oder primäre OBD-Steuermodul das RBMS-Paketsignal, das durch das empfangende Steuermodul verwendet wird, um ratenbasierte Zähler und Nenner für ratenbasierte Überwachungen zu inkrementieren, die zu dem übertragenden sekundären und/oder abhängigen sekundären OBD-Steuermodul gehören. Das Master- und/oder das primäre OBD-Steuermodul implementiert eine ratenbasierte Nutzenfunktion, um ein korrektes Inkrementieren und eine korrekte Speicherung von ratenbasierten Zählern und Nennern zu ermöglichen, und stellt sicher, dass ratenbasierte Zähler und Nenner nicht mehr als einmal pro Zündzyklus inkrementiert und gespeichert werden. Das empfangende Steuermodul ignoriert das RBMS-Paketsignal für eine Schwellenwertzeitdauer (z.B. 5 Sekunden) zu Beginn jedes Standard-OBD-Fahrzyklus. Auf diese Weise werden mehrere Zähler- und/oder Nennerinkrementierungen innerhalb eines einzelnen Zündzyklus verhindert. Der primäre Zweck des RBMS-Paketsignals ist, eine Speicherung von im Betrieb befindlichen Verhältnissen in dem Master- und/oder dem primären OBD-Steuermodul zu ermöglichen, so dass das sekundäre und/oder das abhängige sekundäre OBD-Steuermodul keine ratenbasierte Infrastruktur, Software und keinen NVM erfordert.
Das Master- und/oder das primäre OBD-Steuermodul überträgt das Diagnoseinformationslösch-Signal (CDI-Signal), das mit FALSCH initialisiert ist, wenn das Master- und/oder das primäre OBD-Steuermodul angeschaltet wird. Das CDI-Signal wird nur auf WAHR gesetzt, wenn das Master- und/oder das primäre OBD-Steuermodul einen korrekt formatierten Diagnosecodelösch-Befehl (DCC-Befehl) empfängt, der über einen Befehl für ein Löschen/Zurücksetzen aller mit Emissionen in Verbindung stehenden Diagnoseinformationen (d.h. Modus $04) von dem generischen Abtastwerkzeug erzeugt wird. Wenn das CDI-Signal auf WAHR gesetzt wird, bleibt es für die Zeitdauer WAHR, für die das Master- und/oder das primäre OBD-Steuermodul keine Fehlercodes speichert, die ihm von einem beliebigen anderen OBD-Steuermodul berichtet werden, und geht dann auf FALSCH über. Es sei angemerkt, dass einige empfangende OBD-Steuermodule das CDI-Signal basierend auf einer programmspezifischen seriellen Datenarchitektur und anderen Betrachtungen über ein Gateway an ein abhängiges sekundäres OBD-Steuermodul liefern können, das ihm einen Fehlerstatus berichtet.
Das empfangende abhängige sekundäre OBD-Steuermodul überwacht das CDI-Signal kontinuierlich über den Zündzyklus. Wenn sich das CDI-Signal von FALSCH auf WAHR ändert, löscht das empfangende abhängige sekundäre OBD-Steuermodul alle Informationen und/oder setzt alle Informationen zurück, die alle Fehlerdiagnose-/ratenbasierten Diagnosezählwerte und temporären Fehlercodes in dem Speicher umfassen, jedoch nicht darauf beschränkt sind. Diese Anforderung betrifft nur jene DTCs, deren Status über ein Diagnosestatus-Signal berichtet wird. Bei einem Verlust der Kommunikation mit dem übertragenden OBD-Steuermodul behält das empfangende OBD-Steuermodul seine Funktion so bei, als ob das CDI-Signal auf FALSCH gesetzt wäre.
Das der ESD oder dem Batteriepaket zugehörige sekundäre OBD-Steuermodul (d.h. das BPCM) überträgt mehrere (z.B. 4) Batteriepaketdiagnosestatus-Paketsignale (BPDS-Paketsignale). Diese Signale werden verwendet, um den Status aller DTCs zu berichten, die mit dem Batteriepaket in Verbindung stehen. Jedes BPDS-Paketsignal umfasst zwei Teilsignale, um durch periodisches zyklisches Durchlaufen aller Diagnoseindizes den Status mehrerer Diagnosen (z.B. 32) von jenen Diagnosen, die unterstützt sind, und jenen, die dies nicht sind, zu berichten. Wenn das sekundäre OBD-Steuermodul z.B. tatsächlich nur eine Teilmenge von Diagnosen der gesamten möglichen Diagnosen unterstützt, weist das BPDS-Paketsignal für alle nicht unterstützten Diagnosen einen nicht unterstützten Status auf.
Bei einem Anschalten umfasst das erste BPDS-Paketsignal eine Diagnoseinformation für den ersten Diagnoseindex (z.B. Diagnoseindex = 0). Wenn mehr als 32 Diagnoseindizes berichtet werden, umfasst das zweite BPDS-Paketsignal eine Diagnoseinformation für die 33. Diagnose (z.B. Diagnoseindex = 0) und so weiter. Nach dem Übertragen der letzten Diagnose (z.B. Diagnoseindex = 31) startet der Prozess für jedes BPDS-Paketsignal durch Senden eines Frames für die erste Diagnose von neuem. Als ein Ergebnis von Verzögerungen zwischen einer Fehlerdetektion und einer Benachrichtigung des empfangenden primären OBD-Steuermoduls (d.h. des HCP) kann das empfangende primäre OBD-Steuermodul weder diese Nachrichten noch die in dem empfangenden OBD-Steuermodul gespeicherten DTCs verwenden, um Standardbetriebsmodi zu aktivieren. Standardmodi, die eine schnellere Benachrichtigung erfordern, müssen Gültigkeits-Flags oder einen anderen Mechanismus verwenden, der direkt zu den entsprechenden verwendeten Eingangsdaten gehört. Der primäre Zweck des BPDS-Paketsignals ist, eine DTC-Speicherung in dem empfangenden primären OBD-Steuermodul zu ermöglichen, ohne dass es erforderlich ist, dass das übertragende sekundäre OBD-Steuermodul die Last einer Diagnoseinfrastruktursoftware trägt. Der berichtete DTC-Index und der zugehörige Status werden wie oben beschrieben mit der periodischen Übertra gungsrate inkrementiert oder aktualisiert. Der DTC-Index und der zugehörige Status werden nicht schneller als die periodische Übertragungsrate inkrementiert oder aktualisiert, so dass kein DTC-Index und kein zugehöriger Status verloren geht.
Die BPDS-Paketsignale umfassen den DTC-Index und den DTC-Status. Der DTC-Index wird als ein Index für eine Tabelle von unterstützten DTCs verwendet und gibt den bestimmten DTC an, dessen Status in dem DTC-Status angegeben ist. Der DTC-Status umfasst den Diagnoseteststatus des DTC, der in dem DTC-Index angegeben ist.
Beim Anschalten wird der Diagnoseteststatus für jeden nicht unterstützten DTC mit NICHT UNTERSTÜTZT initialisiert, und wird der Diagnoseteststatus für jeden unterstützten DTC mit KEIN STATUS ZU BERICHTEN initialisiert, bis der Diagnosetest deaktiviert wird oder eine BESTANDEN/VERSAGT-Entscheidung abschließt. Wenn ein Diagnosetest kritisch deaktiviert wird, bleibt der berichtete Status in dem kritisch deaktivierten Zustand, bis die Deaktivierungszustände nicht mehr existieren, und zu diesem Zeitpunkt wird der Diagnosetest mit den Anschaltwerten neu initialisiert. Nach einem Berichten eines BESTANDEN- oder VERSAGT-Status wird der Diagnosestatus mit den Anschaltwerten neu initialisiert, bis eine andere BESTANDEN/VERSAGT-Entscheidung getroffen wird. Dies ist erforderlich, da das primäre OBD-Steuermodul den Diagnosestatus für jeden DTC über ein 1-Byte-DTC-Statussignal an Servicetechniker liefert, sodass das Wartungswerkzeug den Echtzeitstatus direkt anzeigen kann. Nach einem Codelöschen in dem primären OBD-Steuermodul verwirft das primäre OBD-Steuermodul jeglichen empfangenen Diagnosestatus und beendet ein Berichten an die Diagnosedatenverwaltungseinrichtung für eine Schwellenwertzeitdauer (z.B. 2–3 Sekunden).
Das sekundäre OBD-Steuermodul ist verantwortlich, um für jede Diagnose zu ermitteln, wann der DTC-Status DIAGNOSE BESTANDEN oder DIAGNOSE VERSAGT lautet. Ein DTC-Status KRITISCH DEAKTIVIERT gibt an, dass ein Diagnosetest auf solch eine Weise deaktiviert ist, dass es für den Fahrer keine Möglichkeit gibt, das Fahrzeug für den Rest des Standard-OBD-Fahrzyklus zu betreiben und den Diagnosetest laufen zu lassen.
Das zugehörige primäre OBD-Steuermodul empfängt die mehreren BPDS-Paketsignale, die durch das primäre OBD-Steuermodul verwendet werden, um Fehler zu speichern und für den DTC ein BESTANDEN/VERSAGT zu berichten. Als ein Ergebnis von Verzögerungen zwischen einer Fehlerdetektion und einer Benachrichtigung des primären OBD-Steuermoduls kann das primäre OBD-Steuermodul weder diese Nachrichten noch die in dem primären OBD-Steuermodul gespeicherten DTCs verwenden, um Standardbetriebsmodi zu aktivieren. Standardmodi, die eine schnellere Benachrichtigung erfordern, müssen Gültigkeits-Flags verwenden, die zu den entsprechenden verwendeten Batteriepaketdaten gehören.
Der primäre Zweck der BPDS-Paketsignale ist, eine DTC-Speicherung in dem primären OBD-Steuermodul zu ermöglichen, ohne zu erfordern, dass das zugehörige sekundäre OBD-Steuermodul die Last einer konformitätsbezogenen OBD-Infrastruktursoftware trägt. Es sei auch angemerkt, dass die BPDS-Paketsignale auch zum Übertragen des Status von Nicht-OBD-Fehlern verwendet werden können.
Die abhängigen sekundären OBD-Steuermodule, die zu dem TPIM gehören (d.h. der MCPA und der MCPB), übertragen Motorsteuersystem-A/B-Diagnosestatus-Paketsignale (MCSDS-Paketsignale) an das zugehörige primäre OBD-Steuermodul (d.h. den HCP). Die MCSDS-Paketsignale werden verwendet, um den Status aller DTCs zu berichten, die mit den übertragenden abhängigen sekundären OBD-Steuermodulen in Verbindung stehen. Die abhängigen sekundären OBD-Steuermodule verwenden die MCSDS-Paketsignale, um den Status mehrerer Diagnosen (z.B. 32) einschließlich jener, die unterstützt sind, und jener, die dies nicht sind, durch periodisches zyklisches Durchlaufen aller Diagnoseindizes zu berichten. Wenn die abhängigen sekundären OBD-Steuermodule z.B. tatsächlich nur eine Teilmenge der gesamten Diagnosen unterstützen, würde das MCSDS-Paketsignal für alle nicht unterstützten Diagnosen mit einem Status gesendet werden, der gleich NICHT UNTERSTÜTZT ist.
Beim Anschalten umfasst das erste MCSDS-Paketsignal die Diagnoseinformation für die erste Diagnose (z.B. Diagnoseindex = 0). Wenn mehr als 32 Diagnoseindizes berichtet werden, umfasst das zweite MCSDS-Paketsignal die Diagnoseinformation für die 33. Diagnose (z.B. Diagnoseindex = 0) und so weiter. Nach einem Übertragen der letzten Diagnose (z.B. Diagnoseindex = 31) startet der Prozess für jedes MCSDS-Paketsignal von neuem durch Senden eines Frames für die erste Diagnose. Als ein Ergebnis von Verzögerungen zwischen einer Fehlerdetektion und einer Benachrichtigung des empfangenden primären OBD-Steuermoduls kann das empfangende primäre Steuermodul weder diese Nachrichten noch die in dem primären OBD-Steuermodul gespeicherten DTCs verwenden, um Standardbetriebsmodi zu aktivieren. Standardmodi, die eine schnellere Benachrichtigung erfordern, müssen Gültigkeits-Flags oder einen anderen Mechanismus verwenden, der direkt zu den entsprechenden verwendeten Eingabedaten gehört. Der primäre Zweck der MCSDS-Paketsignale ist, einen DTC-Speicher in dem primären OBD-Steuermodul bereitzustellen, ohne dass die übertragenden sekundären abhängigen OBD-Steuermodule eine Diagnoseinfrastruktursoftware erfordern. Der berichtete DTC-Index und der zugehörige Status werden wie oben beschrieben mit der periodi schen Übertragungsrate inkrementiert oder aktualisiert. Der DTC-Index und der zugehörige Status werden nicht schneller als die periodische Übertragungsrate inkrementiert oder aktualisiert, so dass kein DTC-Indexwert und kein zugehöriger Status verloren geht.
Der DTC-Index wird als ein Index für die Tabelle von unterstützten DTCs verwendet und gibt den bestimmten DTC an, dessen Status durch das DTC-Statussignal bereitgestellt wird. Der DTC-Status stellt den Diagnoseteststatus des durch das DTC-Indexsignal angegebenen DTC bereit. Bei einem Anschalten wird der Diagnoseteststatus für jeden nicht unterstützten DTC mit NICHT UNTERSTÜTZT initialisiert, und wird der Diagnoseteststatus für jeden unterstützten DTC mit KEIN STATUS ZU BERICHTEN initialisiert, bis der Diagnosetest deaktiviert wird oder eine BESTANDEN/VERSAGT-Entscheidung abschließt.
Wenn ein Diagnosetest kritisch deaktiviert wird, bleibt der berichtete Status in dem kritisch deaktivierten Zustand, bis die Deaktivierungszustände nicht mehr existieren, und zu diesem Zeitpunkt wird der Diagnosetest mit den Anschaltwerten neu initialisiert. Nach dem Berichten eines BESTANDEN- oder VERSAGT-Status wird der Diagnosestatus mit den Anschaltwerten neu initialisiert, bis eine andere BESTANDEN/VERSAGT-Entscheidung gefällt wird. Dies ist erforderlich, da das empfangende primäre OBD-Steuermodul den Diagnosestatus für jeden DTC über das Wartungswerkzeug an Servicetechniker liefert, um den Echtzeitstatus direkt anzuzeigen. Nach einem Codelöschen in dem primären OBD-Steuermodul verwirft das primäre Steuermodul jegliche empfangenen Diagnosestatus und beendet das Berichten an die Diagnosedatenverwaltungseinrichtung für eine Schwellenwertzeitdauer (z.B. 2–3 Sekunden). Die abhängigen sekundären OBD-Steuermodule sind verantwortlich, um für jede Diagnose zu ermitteln, wann der DTC-Status Diagnose Bestanden oder Diagnose Versagt sein sollte. Ein DTC-Status Kritisch Deaktiviert gibt an, wenn ein Diagnosetest auf solch eine Weise deaktiviert wird, dass für den Fahrer keine Möglichkeit besteht, das Fahrzeug zu betreiben und den Diagnosetest laufen zu lassen.
Die MCSDS-Paketsignale werden durch das zugehörige primäre OBD-Steuermodulempfangen, das die MCSDS-Paketsignale verwendet, um Fehler zu speichern und für den DTC ein BESTANDEN/VERSAGT zu berichten. Als ein Ergebnis von Verzögerungen zwischen einer Fehlerdetektion und einer Benachrichtigung des primären OBD-Steuermoduls kann das primäre OBD-Steuermodul weder diese Nachrichten noch die in dem primären OBD-Steuermodul gespeicherten DTCs verwenden, um Standardbetriebsmodi zu aktivieren. Standardmodi, die eine schnellere Benachrichtigung erfordern, müssen Gültigkeits-Flags verwenden, die zu den entsprechenden verwendeten Daten gehören. Der primäre Zweck der MCSDS-Paketsignale ist, eine DTC-Speicherung in dem primären OBD-Steuermodul zu verwenden, ohne dass die abhängigen sekundären OBD-Steuermodule eine konformitätsbezogene OBD-Infrastruktursoftware erfordern. Es sei auch angemerkt, dass die MCSDS-Paketsignale auch den Status von Nicht-OBD-Fehlern übertragen können.
Das Steuermodulkalibrierungsidentifikationsinformations-Paketsignal (CMCII-Paketsignal) wird verwendet, um die Kalibrierungsidentifikation (CID) und die Kalibrierungsverifikationszahl-Daten (CVN-Daten) von einem primären, sekundären und/oder abhängigen sekundären OBD-Steuermodul an sein Host-OBD-Steuermodul zu übertragen. Alle in dem bestimmten OBD-Steuermodul gespeicherten Software- und Kalibrierungsdaten sind in einer oder mehreren CIDs und zugehörigen CVNs gespeichert.
Ein Kalibrierungsidentifikationsindex (CII) wird bereitgestellt und stellt einen laufenden Index dar, der ermöglicht, bis zu 16 CIDs und zugehörige CVNs zu übertragen. Für alle CIDs, die durch das bestimmte OBD-Steuermodul unterstützt werden, wird ein zusammenhängender Satz von Indizes verwendet, die mit dem Index 0 starten. Der CII bleibt konstant, bis alle zugehörigen Frames einer CID und einer CVN übertragen wurden (z.B. drei Übertragungen jedes Index vor einer Indexänderung).
Ein Datenstatus (DS) ist vorgesehen und gibt den Status der momentan übertragenen Daten an. Der DS weist drei Zustände auf: CII Nicht Verwendet, CVN Nicht Berechnet und CVN Berechnet. Der CII Nicht Verwendet-DS-Zustand gibt an, dass der übertragene Index keine CID- oder CVN-Information enthält. Der CVN Nicht Berechnet-DS-Zustand gibt an, dass die CVN während diesem Zündzyklus nicht berechnet wurde, während eine CID-Information für den CII übertragen wird. Der CVN Berechnet-DS-Status gibt an, dass die CID und die bei diesem Zündzyklus berechnete CVN für den momentanen CII übertragen werden. Eine Sequenzzahl (SN) ist vorgesehen und läuft für jeden CII zyklisch von Null bis Zwei. Die SN gibt den Frame von Daten an, der übertragen wird, und ermöglicht dem empfangenden OBD-Steuermodul, die zwanzig Byte von Daten für jeden CII korrekt zu kombinieren.
Das empfangende OBD-Steuermodul verwendet den CII und die SN, um die CID- und CVN-Daten neu zu konstruieren und sie mit ihrem Datenstatus in Verbindung zu bringen. Das empfangende OBD-Steuermodul liefert auch 20 Byte von entweder einem zündungsunabhängigen oder einem batterieunabhängigen Speicher zur Speicherung von jeder empfangenen CID und CVN und stellt auch einen Speicher zum Speichern des Speicherstatus aller CID und CVN bereit. Auf diese Weise unterscheidet das empfangende OBD-Steuermodul zwischen CII, die nicht verwendet werden, die Teilenummern haben, die nicht empfangen wurden, die CVNs haben, die nicht berechnet wurden, oder die Teilenummern und CVNs haben, die empfangen und gespeichert wurden. Das empfangende OBD-Steuermodul speichert die letzten empfangenen CIDs und die zugehörigen CVNs sowie den Empfangsstatus jedes CII. Wenn eine neue CID empfangen wird, wobei die CVN nicht berechnet ist, wird die CID als eine CID mit einer nicht berechneten CVN gespeichert und markiert, bis eine berechnete CVN empfangen wird.
Daten werden nur verarbeitet und gespeichert, wenn die 3 Frames, die den CII bilden, als 3 zusammenhängende Frames empfangen werden. Diese Daten werden mit den eigenen Fahrzeuginformationstypdaten des empfangenden OBD-Steuermoduls (d.h. Modus $09) berichtet, wenn solch eine Antwort bereitgestellt wird. Daten von den CIIs mit einem DS von CII Nicht Verwendet sind in den berichteten Fahrzeuginformationstypdaten nicht umfasst.
Die verteilte Diagnosearchitektur der vorliegenden Erfindung verteilt eine OBD-Funktionalität in einem Steuersystem, das mehrere Systeme mit entsprechenden Steuermodulen umfasst. Genauer gesagt stellt die verteilte Diagnosearchitektur ein allgemeines Mittel für ein Fahrzeug bereit, um Diagnosen und eine in Verbindung stehende Information zwischen mehreren Fahrzeugsteuermodulen zu koordinieren, stellt die verteilte Diagnosearchitektur eine Konformität mit staatlichen Regelungen sicher und sorgt die verteilte Diagnosearchitektur für eine Fahrzeugtauglichkeit bei solchen komplexen Systemen. Die Anzahl von Steuermodulen mit geregelten OBD-Einrichtungs-IDs kann auch reduziert werden, ohne die Anzahl von OBD-Steuermodulen für eine gegebene Anwendung zu reduzieren.
Fachleute können nun aus der vorangehenden Beschreibung erkennen, dass die breiten Lehren der vorliegenden Erfindung auf eine Vielzahl von Formen realisiert werden können. Daher sollte, während diese Erfindung in Verbindung mit bestimmten Beispielen hiervon beschrieben wurde, der wahre Schutzumfang der Erfindung nicht so beschränkt sein, da andere Abwandlungen für den Fachmann bei einem Studieren der Zeichnungen, der Beschreibung und der folgenden Ansprüche ersichtlich werden.

Claims

Verteilte fahrzeugeigene Diagnosearchitektur (OBD-Architektur) für ein Steuersystem eines Fahrzeugs, umfassend: mehrere Steuermodule, die miteinander in Verbindung stehen; und ein designiertes Master-OBD-Steuermodul, das eines der mehreren Steuermodule ist, wobei das Master-OBD-Steuermodul Funktionen ausführt, die ein Rest der mehreren Steuermodule nicht ausführen kann, umfassend ein Arbitrieren eines Störungsanzeigeleuchten-Zustands (MIL-Zustands) und/oder ein Arbitrieren und Speichern von OBD-Einzelbilddaten und/oder ein Ermitteln von OBD-Status-Flags des Rests der mehreren Steuermodule.
Verteilte OBD-Architektur nach Anspruch 1, wobei jedes der mehreren Steuermodule einen OBD-Algorithmus ausführt, um zu überwachen, ob ein Eingang und/oder ein Ausgang und/oder ein System, der bzw. das zu einem bestimmten Steuermodul gehört, korrekt funktionieren bzw. funktioniert.
Verteilte OBD-Architektur nach Anspruch 1, wobei jedes der mehreren Steuermodule eine Selbstdiagnose ausführt.
Verteilte OBD-Architektur nach Anspruch 3, wobei die Selbstdiagnose eine Prüfung von ROM und/oder RAM und/oder anderen Speichereinrichtungen und/oder allen anderen mit Emissionen in Ver bindung stehenden Peripherieeinrichtungen innerhalb des bestimmten Steuermoduls umfasst.
Verteilte OBD-Architektur nach Anspruch 1, wobei jedes der mehreren Steuermodule eine ratenbasierte Diagnoseüberwachung inkrementiert, wenn ihm eine zugeordnet ist.
Verteilte OBD-Architektur nach Anspruch 1, ferner umfassend ein designiertes primäres OBD-Steuermodul, das eines der mehreren Steuermodule ist, wobei das Master-OBD-Steuermodul und das primäre OBD-Steuermodul mindestens einen Diagnosefehlercode (DTC) speichern, der einem des Rests der mehreren Steuermodule entspricht, das zu dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul gehört, und ihre eigenen DTCs speichern.
Verteilte OBD-Architektur nach Anspruch 1, ferner umfassend ein designiertes primäres OBD-Steuermodul, das eines der mehreren Steuermodule ist, wobei das Master-OBD-Steuermodul und das primäre OBD-Steuermodul mindestens einen ratenbasierten Überwachungswert speichern, der einem des Rests der mehreren Steuermodule entspricht, das zu dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul gehört, und ihre eigenen ratenbasierten Überwachungswerte speichern.
Verteilte OBD-Architektur nach Anspruch 1, ferner umfassend ein designiertes primäres OBD-Steuermodul, das eines der mehreren Steuermodule ist, wobei das Master-OBD-Steuermodul und das primäre Steuermodul über ein Gateway OBD-Signale zwischen einem ersten Kommunikationsbus und einem zweiten Kommunikationsbus liefern.
Verteilte OBD-Architektur nach Anspruch 1, ferner umfassend ein designiertes primäres OBD-Steuermodul, das eines der mehreren Steuermodule ist, wobei das Master-OBD-Steuermodul und das primäre Steuermodul eine Kalibrierungsidentifikations- und eine Kalibrierungsverifikationszahlinformation von mindestens einem des Rests der mehreren Steuermodule speichern und berichten, das zu dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul gehört.
Verteilte OBD-Architektur nach Anspruch 1, ferner umfassend ein designiertes primäres OBD-Steuermodul, das eines der mehreren Steuermodule ist, wobei das primäre OBD-Steuermodul dem Master-OBD-Steuermodul Signale liefert, die ein mit Emissionen in Verbindung stehendes DTC-Signal und/oder ein mit Emissionen in Verbindung stehendes Störungsaktivsignal umfassen.
Verteilte OBD-Architektur nach Anspruch 1, ferner umfassend ein designiertes primäres OBD-Steuermodul und ein designiertes sekundäres Steuermodul der mehreren Steuermodule, wobei das sekundäre Steuermodul dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul eine zugehörige ratenbasierte Überwachungsinformation liefert.
Verteilte OBD-Architektur nach Anspruch 11, ferner umfassend ein designiertes abhängiges sekundäres OBD-Steuermodul der mehreren Steuermodule, das ein Löschen einer Diagnoseinformation auf der Grundlage von lediglich einer Anweisung von dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul und/oder ein Liefern einer Kalibrierungsidentifikations- und einer Kalibrierungs verifikationszahlinformation an ein zugehöriges Host-Steuermodul ausführt.
Verfahren zum Verteilen von fahrzeugeigenen Diagnosefunktionen (OBD-Funktionen) in einem Steuersystem eines Fahrzeugs, das umfasst, dass mehrere Steuermodule für eine Kommunikation miteinander verbunden werden; eines der mehreren Steuermodule als ein OBD-Master-Steuermodul designiert wird; Funktionen unter Verwendung des OBD-Master-Steuermoduls ausgeführt werden, die ein Rest der mehreren Steuermodule nicht ausführen kann, umfassend ein Arbitrieren eines Störungsanzeigeleuchten-Zustands (MIL-Zustands) und/oder ein Arbitrieren und Speichern von OBD-Einzelbilddaten und/oder ein Ermitteln von OBD-Status-Flags des Rests der mehreren Steuermodule.
Verfahren nach Anspruch 13, wobei jedes der mehreren Steuermodule einen OBD-Algorithmus ausführt, um zu überwachen, ob ein Eingang und/oder ein Ausgang und/oder ein System, der bzw. das zu einem bestimmten Steuermodul gehört, korrekt funktionieren bzw. funktioniert.
Verfahren nach Anspruch 13, das ferner umfasst, dass eine Selbstdiagnose für jedes der mehreren Steuermodule ausgeführt wird.
Verfahren nach Anspruch 15, wobei die Selbstdiagnose eine Prüfung von ROM und/oder RAM und/oder anderen Speichereinrichtungen und/oder allen anderen mit Emissionen in Verbindung stehenden Peripherieeinrichtungen in dem bestimmten Steuermodul umfasst.
Verfahren nach Anspruch 13, wobei jedes der mehreren Steuermodule eine ratenbasierte Diagnoseüberwachung inkrementiert, wenn ihm eine zugeordnet ist.
Verfahren nach Anspruch 13, das ferner umfasst, dass eines der mehreren Steuermodule als ein primäres OBD-Steuermodul designiert wird, wobei das Master-OBD-Steuermodul und das primäre OBD-Steuermodul mindestens einen Diagnosefehlercode (DTC) speichert, der einem des Rests der mehreren Steuermodule entspricht, das zu dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul gehört, und ihre eigenen DTCs speichern.
Verfahren nach Anspruch 13, das ferner umfasst, dass eines der mehreren Steuermodule als ein primäres OBD-Steuermodul designiert wird, wobei das Master-OBD-Steuermodul und das primäre OBD-Steuermodul mindestens einen ratenbasierten Überwachungswert speichern, der einem des Rests der mehreren Steuermodule entspricht, das zu dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul gehört, und ihre eigenen ratenbasierten Überwachungswerte speichern.
Verfahren nach Anspruch 13, das ferner umfasst, dass eines der mehreren Steuermodule als ein primäres OBD-Steuermodul designiert wird, wobei das Master-OBD-Steuermodul und das primäre Steuermodul über ein Gateway OBD-Signale zwischen einem ersten Kommunikationsbus und einem zweiten Kommunikationsbus liefern.
Verfahren nach Anspruch 13, das ferner umfasst, dass eines der mehreren Steuermodule als ein primäres OBD-Steuermodul designiert wird, wobei das Master-OBD-Steuermodul und das primäre Steuermodul eine Kalibrierungsidentifikations- und eine Kalibrierungsverifikationszahlinformation von mindestens einem des Rests der mehreren Steuermodule speichern und berichten, das zu dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul gehört.
Verfahren nach Anspruch 13, das ferner umfasst, dass eines der mehreren Steuermodule als ein primäres OBD-Steuermodul designiert wird, wobei das primäre OBD-Steuermodul dem Master-OBD-Steuermodul Signale liefert, die ein mit Emissionen in Verbindung stehendes DTC-Signal und/oder ein mit Emissionen in Verbindung stehendes Störungsaktivsignal umfassen.
Verfahren nach Anspruch 13, das ferner umfasst, dass eines der mehreren Steuermodule als ein primäres OBD-Steuermodul designiert wird und eines der mehreren Steuermodule als ein sekundäres Steuermodul designiert wird, wobei das sekundäre Steuermodul dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul eine zugehörige ratenbasierte Überwachungsinformation liefert.
Verfahren nach Anspruch 23, das ferner umfasst, dass eines der mehreren Steuermodule als ein abhängiges sekundäres OBD-Steuermodul designiert wird, das ein Löschen einer Diagnoseinformation auf der Grundlage von lediglich einer Anweisung von dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul und/oder ein Liefern einer Kalibrierungsidentifikations- und einer Kalibrierungsverifikationszahlinformation an ein zugehöriges Host-Steuermodul ausführt.
Verteilte fahrzeugeigene Diagnosearchitektur (OBD-Architektur) für ein Steuersystem eines Fahrzeugs, umfassend: eine erste Mehrzahl von Steuermodulen, die miteinander über einen ersten Kommunikationsbus in Verbindung stehen; eine zweite Mehrzahl von Steuermodulen, die miteinander über einen zweiten Kommunikationsbus in Verbindung stehen; und ein designiertes Master-OBD-Steuermodul, das eines der ersten und zweiten Mehrzahlen von Steuermodulen ist, wobei das Master-OBD-Steuermodul Funktionen ausführt, die ein Rest der ersten und zweiten Mehrzahlen von Steuermodulen nicht ausführen kann, umfassend ein Arbitrieren eines Störungsanzeigeleuchten-Zustands (MIL-Zustands) und/oder ein Arbitrieren und Speichern von OBD-Einzelbilddaten und/oder ein Ermitteln von OBD-Status-Flags des Rests der ersten und zweiten Mehrzahlen von Steuermodulen.
Verteilte OBD-Architektur nach Anspruch 25, wobei die ersten und zweiten Mehrzahlen von Steuermodulen einen OBD-Algorithmus ausführen, um zu überwachen, ob ein Eingang und/oder ein Ausgang und/oder ein System, der bzw. das zu einem bestimmten Steuermodul gehört, korrekt funktionieren bzw. funktioniert.
Verteilte OBD-Architektur nach Anspruch 25, wobei die ersten und zweiten Mehrzahlen von Steuermodulen eine Selbstdiagnose ausführen.
Verteilte OBD-Architektur nach Anspruch 27, wobei die Selbstdiagnose eine Prüfung von ROM und/oder RAM und/oder anderen Spei chereinrichtungen und/oder allen anderen mit Emissionen in Verbindung stehenden Peripherieeinrichtungen innerhalb des bestimmten Steuermoduls umfasst.
Verteilte OBD-Architektur nach Anspruch 25, wobei jedes der ersten und zweiten Mehrzahlen von Steuermodulen eine ratenbasierte Diagnoseüberwachung inkrementiert, wenn ihm eine zugeordnet ist.
Verteilte OBD-Architektur nach Anspruch 25, ferner umfassend ein designiertes primäres OBD-Steuermodul, das eines der ersten und zweiten Mehrzahlen von Steuermodulen ist.
Verteilte OBD-Architektur nach Anspruch 30, wobei das Master-OBD-Steuermodul und das primäre OBD-Steuermodul mindestens einen Diagnosefehlercode (DTC) speichern, der einem des Rests der ersten und zweiten Mehrzahlen von Steuermodulen entspricht, das zu dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul gehört, und ihre eigenen DTCs speichern.
Verteilte OBD-Architektur nach Anspruch 30, wobei das Master-OBD-Steuermodul und das primäre OBD-Steuermodul mindestens einen ratenbasierten Überwachungswert speichern, der einem des Rests der ersten und zweiten Mehrzahlen von Steuermodulen entspricht, das zu dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul gehört, und ihre eigenen ratenbasierten Überwachungswerte speichern.
Verteilte OBD-Architektur nach Anspruch 30, wobei das Master-OBD-Steuermodul und das primäre Steuermodul über ein Gateway OBD-Signale zwischen dem ersten Kommunikationsbus und dem zweiten Kommunikationsbus liefern.
Verteilte OBD-Architektur nach Anspruch 30, wobei das Master-OBD-Steuermodul und das primäre Steuermodul eine Kalibrierungsidentifikations- und eine Kalibrierungsverifikationszahlinformation von mindestens einem des Rests der ersten und zweiten Mehrzahlen von Steuermodulen speichert und berichtet, das zu dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul gehört.
Verteilte OBD-Architektur nach Anspruch 30, wobei das primäre OBD-Steuermodul dem Master-OBD-Steuermodul Signale liefert, die ein mit Emissionen in Verbindung stehendes DTC-Signal und/oder ein mit Emissionen in Verbindung stehendes Störungsaktivsignal umfassen.
Verteilte OBD-Architektur nach Anspruch 30, ferner umfassend ein designiertes sekundäres Steuermodul der ersten und zweiten Mehrzahlen von Steuermodulen, wobei das sekundäre Steuermodul eine zugehörige ratenbasierte Überwachungsinformation an das Master-OBD-Steuermodul oder das primäre OBD-Steuermodul liefert.
Verteilte OBD-Architektur nach Anspruch 36, ferner umfassend ein designiertes abhängiges sekundäres OBD-Steuermodul der ersten und zweiten Mehrzahlen von Steuermodulen, das ein Löschen einer Diagnoseinformation auf der Grundlage von lediglich einer Anweisung von dem Master-OBD-Steuermodul oder dem primären OBD-Steuermodul und/oder ein Liefern einer Kalibrierungsidentifikati ons- und einer Kalibrierungsverifikationszahlinformation an ein zugehöriges Host-Steuermodul ausführt.