DE3928537A1 - Verfahren zur fehlererkennung und/oder fehlerlokalisation bei datenuebertragungen - Google Patents

Description

Stand der Technik

Die Erfindung betrifft ein Verfahren zur Fehlerer­ kennung und/oder Fehlerlokalisation bei Datenüber­ tragungen über ein Netzwerk, insbesondere CAN (Con­ troller Aera Network).

Bei der Datenübertragung über ein als Datenbus aus­ gebildetes Netzwerk können die verschiedensten Feh­ ler auftreten. Die Erfindung bezieht sich auf eine Fehlerdetektion und -lokalisation bei einer derar­ tigen Datenübertragung.

Vorteile der Erfindung

Das erfindungsgemäße Verfahren mit den im Haupt­ anspruch genannten Merkmalen ermöglicht die Prüfung von Störungen bei der Datenübertragung und deren mögliche Detektion und Lokalisation durch Software. Diese softwaremäßige Fehlererkennung erfordert keinen apparativen Aufwand und läßt sich daher auf besonders einfache Weise installieren. Grundprinzip der im nachfolgenden detailiert beschriebenen ver­ schiedenen Fehlererkennungen ist es, daß nach Ab­ gabe eines Signals eine Prüfung erfolgt, ob inner­ halb einer vorgegebenen Zeit eine auf dem Signal beruhende Zustandsänderung eintritt und daß beim Ausbleiben der Zustandsänderung eine Fehlermeldung erfolgt. Tritt also nicht innerhalb der vorge­ gebenen Zeit, die von bestimmten Kriterien abhängig ist, eine Reaktion auf ein Ereignis ein, so wird dieses auf Störungen zurückgeführt, die keinen kor­ rekten Datenverkehr zulassen.

Das erfindungsgemäße Verfahren ist insbesondere zur Anwendung in der Kraftfahrzeugelektronik geeignet. Das Netzwerk, das z.B. als CAN-BUS ausgebildet ist, verbindet verschiedene elektronische Einrichtungen, insbesondere Steuergeräte, des Kraftfahrzeugs. Diese Steuergeräte dienen zusammen mit geeigneten Sensoren der Erfassung und Verarbeitung von aktuel­ len Fahrzustandsdaten, denen - rechnergesteuert - zum Beispiel der Betriebszustand der Brennkraftmaschine des Kraftfahrzeugs angepaßt wird (insbesondere Zündwinkel, Zündzeitpunkt, Einspritzzeit usw.). In der modernen Kraftfahrzeugelektronik weist ein Kraftfahrzeug mehrere derartige Steuergeräte auf, die zum Datenaustausch über den erwähnten CAN-BUS miteinander verbunden sind. Diese Steuergeräte wer­ den im nachfolgenden "Teilnehmer" genannt. Jeder Teilnehmer weist eine Zentraleinheit (CPU) auf und besitzt ferner einen BUS-Baustein, insbesondere CAN-Baustein, der die Schnittstelle zwischen dem seriellen BUS, insbesondere CAN-BUS, und den übrigen Einrichtungen des Teilnehmers bildet. Der BUS-Baustein selbst besitzt einen Prozessor (IMP = Interface Management Prozessor), der quasi die Zen­ traleinheit für den BUS-Baustein bildet. Der BUS- Baustein weist ein Controlregister und ein Status­ register auf. Der Zustand des Controlregisters (BIT 0) zeigt an, welche Ansteuerung von der CPU bzw. dem Steuergerät vorliegt. Weist das BIT 0 des Con­ trolregisters den Zustand "1" auf, so ist dieser Zustand gesetzt, das heißt, es liegt eine Reset-An­ forderung vor. Diese Anforderung ist zum Beispiel stets bei einem Start des Kraftfahrzeugs erforder­ lich, um definierte Zustände zu erzeugen. Der Zu­ stand des Statusregisters des BUS-Bausteins zeigt an, in welchem Betriebszustand sich der Baustein befindet. Im nachfolgenden wird hierauf noch näher eingegangen.

Nach einer Weiterbildung der Erfindung ist vorge­ sehen, daß nach dem Ausbleiben einer Betriebs-Zu­ standsänderung das Signal gegebenenfalls noch ein weiteres Mal abgegeben wird. Durch diese Maßnahme, die vorzugsweise mittels einer Programmschleife ge­ steuert/wiederholt wird, erhöht sich die Sicherheit der Fehleraussage. Wenn nach ein-/mehrmaliger Signalabgabe stets die Betriebs-Zustandsänderung ausbleibt, liegt ein Fehler vor.

Insbesondere ist vorgesehen, daß zur Prüfung einer Resetierbarkeit des BUS-Bausteins das Signal ein von der CPU des Steuergeräts gesetzter Resetbefehl zum Setzen eines Resetstatus im Statusregister des BUS-Bausteins ist. Zur Erzielung definierter Zu­ stände ist der BUS-Baustein zu resetieren, was durch einen Resetbefehl der CPU des Steuergeräts erfolgt. Das Setzten des Reset-Request führt dazu, daß das Bit 0 des Controlregisters den Wert "1" an­ nimmt. Erfindungsgemäß wird geprüft, ob im Status­ register nach einer bestimmten Zeit der Resetstatus gesetzt ist. Die bestimmte Zeit soll im Zuge dieser Anmeldung als Resetzeit bezeichnet werden. Sie ist abhängig von mehreren Faktoren, nämlich einerseits vom Taktzyklus des BUS-Bausteins und/oder anderer­ seits auch von dem Taktzyklus der den BUS-Baustein ansprechenden Zentraleinheit. Überdies kann die Re­ setzeit auch noch von dem jeweiligen Betriebszu­ stand des BUS-Bausteins abhängig sein. Erfolgt ein Reset-Request der CPU und setzt der BUS-Baustein gerade eine Sendung ab, so wird diese Sendung nicht sofort unterbrochen, sondern zunächst abgeschlossen und anschließend erst das Bit 0 (Reset Status des Statusregisters) gesetzt. Diese durch das Ab­ schließen der Sendung auftretende "Zeitverzögerung" ist somit bei der Bestimmung der Resetzeit zu be­ rücksichtigen. Ein Fehler des BUS-Bausteins wird gemeldet, wenn innerhalb der Resetzeit kein Reset­ status im Statusregister vorliegt.

Erfolgt eine softwaremäßige Freigabe des BUS-Bau­ steins, wobei hierunter nach einem Reset-Request die anschließend wieder erfolgende Teilnahme am seriellen BUS zu verstehen ist, so wird nach diesem Resetbefehl geprüft, ob innerhalb einer Freigabe­ zeit der Resetstatus durch den Prozessor (IMP) wie­ der aufgehoben wird. Auch hier ist die Freigabezeit von verschiedenen Faktoren, insbesondere von dem Taktzyklus des BUS-Bausteins und/oder dem Taktzy­ klus der Zentraleinheit und/oder dem jeweiligen Be­ triebszustand (Status-Zustand) des BUS-Bausteins abhängig und wird dementsprechend festgelegt. Er­ folgt keine Aufhebung des Resetstatus, so liegt ein Fehler am BUS-Baustein vor.

Vorzugsweise ist vorgesehen, daß während des Em­ pfangs einer Botschaft vorliegenden, von dem Pro­ zessor (IMP) vorgegebenen Zugriffsverbots der Zen­ traleinheit (CPU) eine Zugriffsverbotszeit nicht überschritten werden darf. Unter der Botschaft ist eine Nachricht zu verstehen, die unter anderem einen Identifier und Daten aufweist. Überschreitet das Zugriffsverbot die Zugriffsverbotszeit, die von verschiedenen Faktoren abhängig ist, so ist der korrekte Betrieb des BUS-Bausteins nicht sicherge­ stellt. Die Zugriffsverbotszeit ist von dem Taktzy­ klus und/oder dem jeweiligen Betriebszustand (Sta­ tusregister-Zustand) des BUS-Bausteins abhängig.

Besonders vorteilhaft ist es, wenn eine Prüfung er­ folgt, ob nach einem Zugriffsverbot der Zentralein­ heit ein Setzvorgang des Transferstatus eines dem entsprechenden Kommunikationsobjekt zugehörigen Discriptor-Bytes durchgeführt wird. Erfolgt nach erkanntem Zugriffsverbot der CPU kein von dem IMP durchzuführender Setzvorgang des Transferstatus des zugehörigen Discriptor-Bytes, so ist der korrekte Betrieb des BUS-Bausteins nicht sichergestellt.

Nach einer Weiterbildung der Erfindung ist vorge­ sehen, daß nach jeder über den seriellen BUS em­ pfangenen Nachricht von dem Prozessor (IMP) der Transferstatus gesetzt wird und daß bei der von der Zentraleinheit (CPU) erfolgenden Abfrage der Nach­ richt der Transferstatus gelöscht und die Daten der Nachricht übernommen wird. Eine Prüfung erfolgt nun dahingehend, ob bei höchstens zwei innerhalb einer Abfragezeit von der Zentraleinheit aufeinanderfol­ genden Abfragen ein Transferstatus vorliegt, wobei die Abfragezeit kleiner als die Hälfte der minima­ len Zeit zwischen zwei aufeinanderfolgenden Nach­ richtenanfängen bzw. Nachrichtenenden ist. Ist diese Bedingung eingehalten, so liegt ein korrekter Betrieb vor. Sollte jedoch bei einer weiteren, also dritten Abfrage wiederum ein Transferstatus ermit­ telt werden, so liegt ein Fehler vor. Durchläuft also die CPU-Software den Empfangsteil mehrmals hintereinander, wobei unter mehrmals größer als 2 zu verstehen ist, so läßt sich in Abhängigkeit der Zeitverhältnisse der Nachrichten ein inkorrekter Betrieb feststellen.

Es ist vorgesehen, daß der Empfang einer von einem BUS-Teilnehmer gesendeten Nachricht durch einen anderen BUS-Teilnehmer bestätigt wird, wobei beim Ausbleiben der Empfangsbestätigung stets wieder er­ neut gesendet und der Zählerstand eines Fehlerzäh­ lers jeweils erhöht wird. Jeder unbestätigte Em­ pfang führt daher zu einer Vergrößerung des Zähler­ standes. Überschreitet der Zählerstand einen be­ stimmten Wert (Fehlerzählstand) so wird ein Error­ status im BUS-Baustein gesetzt. Eine Fehlermeldung erfolgt, wenn bei Nichtvorlage des Resetstatus nach einer zuvor gesendeten Nachricht der Transferstatus nicht gesetzt wird und gleichzeitig auch kein Errorstatus vorliegt. Mithin wird der Transfersta­ tus einer zuvor gesendeten Botschaft mit einer Zeitschleife überprüft. Wurde dieser nicht gesetzt und führt die sich stets wiederholende Sendung auch nicht dazu, daß der Fehlerzähler seinen Fehlerzähl­ stand einnimmt, so daß also der Errorstatus nicht gesetzt ist, und es ausgeschlossen ist, daß das Statusregister des BUS-Bausteins einen Resetzustand aufweist, so ist kein korrekter Betrieb gegeben. Die erwähnte Zeitschleife muß ausreichend dimen­ sioniert sein.

Wie bereits ausgeführt, wird beim Ausbleiben der Empfangsbestätigung aufgrund einer gesendeten Nach­ richt stets erneut gesendet und der Zählerstand des Fehlerzählers erhöht. Zunächst wird hierbei der Fehlerzählstand erreicht, der zum Errorstatus führt, der von dem Prozessor (IMP) gesetzt wird. Wenn anschließend auch nach weiteren unbestätigten Sendungen von dem Fehlerzähler ein noch größerer Zählerstand, nämlich ein BUS-Zählstand erreicht wird, so hat dieses ein Setzen des BUS-Status zur Folge. Der BUS-Zählstand ist also größer als der Fehlerzählstand. Liegt ein Fehlerzählstand jedoch kein BUS-Zählstand vor und ist auch kein Transfer­ status gegeben, so ist die Kommunikation aufgrund eines "Kabelbruchs" behindert. Es erfolgt eine BUS- Kabelbruch-Fehlermeldung.

Vorteilhaft ist es, wenn eine Lokalisation eines Fehlers der BUS-Verbindung zwischen mehreren BUS- Teilnehmern dadurch erfolgt, daß an einem BUS-Teil­ nehmer der jedem anderen Teilnehmer zugeordnete Transferstatus überprüft wird. Unter Zugrundelegung des Wissens über die BUS-Kabelführung (Teilnehmer- Anordnung) läßt sich bei einer Kabelunterbrechung diese Unterbrechung lokalisieren, wobei sie sich an einem Ort befindet, der stets zwischen aktiven Teilnehmern liegt. Unter einem aktiven Teilnehmer ist ein Teilnehmer zu verstehen, dessen im ent­ sprechenden Kommunikationsobjekt zugehöriger Trans­ fer-Status überprüft werden kann.

Schließlich ist es vorteilhaft, daß eine Kurz­ schlußfehlermeldung der BUS-Verbindung erfolgt, wenn innerhalb einer Zeitspanne mehrmals ein ge­ setzter BUS-Status vorliegt. Störungen, die bei­ spielsweise durch EMV (elektromagnetische Verträg­ lichkeit) eintreten, können zwar einen gesetzten BUS-Status hervorrufen, jedoch kann dieses in der Regel nicht mehrmals hintereinander auftreten. Vielmehr ist dann auf ein Bus-Fehler (Kurzschluß des CAN-Kabels) zu schließen.

Zeichnung

Die Erfindung wird im folgenden anhand der Figuren näher erläutert. Es zeigen:

Fig. 1 ein Übersichtschaltbild eines CAN-BUSSES mit mehreren Teilnehmern,

Fig. 2 ein Flußdiagramm zur softwaremäßigen Prüfung der Resetierbarkeit eines CAN-Bausteins,

Fig. 3 ein Flußdiagramm zur Überprüfung der softwaremäßigen Freigabe des CAN-Bausteins,

Fig. 4 ein Flußdiagramm zur Überprüfung des Zu­ griffsverbots einer Zentraleinheit eines Steuerge­ räts, wobei das Zugriffsverbot von einem Prozessor des CAN-Bausteins beim Empfang einer Botschaft er­ folgt,

Fig. 5 ein Flußdiagramm zur Überprüfung der korrekten Bestätigung bei vorhergehendem Zugriffs­ verbot in Bezug auf Empfangsnachrichten,

Fig. 6a ein Flußdiagramm zur Überprüfung der korrekten Bestätigung einer empfangenen Botschaft,

Fig. 6b ein Zeitablaufdiagramm zum Flußdiagramm gemäß Fig. 6a,

Fig. 7 ein Flußdiagramm zur Überprüfung der korrekten Bestätigung einer gesendeten Botschaft,

Fig. 8 ein Diagramm zur Überprüfung der BUS- Verbindung des Netzwerks (CAN) und

Fig. 9 ein Flußdiagramm zur Überprüfung des CAN-BUSSES auf Kurzschluß.

Beschreibung der Ausführungsbeispiele

Die Fig. 1 zeigt ein Netzwerk 1, das in einem Kraftfahrzeug untergebracht ist. Es handelt sich hierbei um ein CAN (Controller Aera Network). Das CAN weist einen seriellen BUS 2 auf, der zu mehr­ eren Teilnehmern 3 führt. Die Teilnehmer 3 sind als Steuergeräte 4 ausgebildet. Sie nehmen über nicht dargestellte Sensoren Fahrzustandsdaten und der­ gleichen auf und verarbeiten diese Daten zur Ein­ stellung des Betriebspunktes verschiedener Aggre­ gate des Kraftfahrzeugs. So wird zum Beispiel die Zündung (Zündzeitpunkt, Einspritzzeit, Zündwinkel usw.) in Abhängigkeit von verschiedenen Parametern festgelegt. Jedes Steuergerät 3 besitzt eine Zen­ traleinheit 5, die sogenannte CPU. Ferner weist je­ des Steuergerät 4 einen CAN-Baustein 6 auf. Jeder CAN-Baustein 6 hat einen Prozessor 7, der mit IMP = Interface Management Prozessor bezeichnet wird. Der IMP bildet somit die Zentraleinheit für den je­ weiligen CAN-Baustein 6. Ferner besitzt jeder CAN- Baustein 6 ein Controlregister 8 und ein Status­ register 9.

Die Fig. 2 zeigt ein Flußdiagramm für eine soft­ waremäßige Fehlererkennung im Netzwerk 1. Es soll eine Überprüfung der softwaremäßigen Resetierbar­ keit eines der CAN-Bausteine 6 überprüft werden. Hierdurch ist eine Fehlerlokalisation am CAN-Bau­ stein 6 möglich. Die den betreffenden CAN-Baustein 6 zugehörige CPU des entsprechenden Steuergeräts 4 setzt ein Resetbefehl RB (Reset-Request), wodurch das BIT 0 des entsprechenden Controlregisters 8 den Wert "1" einnimmt. Innerhalb einer bestimmten Zeit muß - bei einwandfreier Funktion des CAN-Bausteins 6 - dessen Statusregister 9 den Resetstatus an­ nehmen. Die vorgegebene Zeit, die als Resetzeit RZ bezeichnet wird, wird in Abhängigkeit von verschie­ denen Faktoren festgelegt. Sie ist vom Taktzyklus des CAN-Bausteins 6 und/oder dem Taktzyklus der ihn ansprechenden CPU abhängig. Ferner besteht eine Ab­ hängigkeit vom jeweiligen Betriebszustand des CAN- Bausteins 6, also eine Einflußnahme durch dessen internen Zustand. Beispielsweise kann ein Setzen durch den Resetbefehl RB während einer Sendung nicht unmittelbar erfolgen, da erst die Sendung ab­ geschlossen wird. Bei der Festlegung der Resetzeit RZ ist dieses zu berücksichtigen. Wird zur Erzie­ lung des Resetstatus′ die Resetzeit RZ überschrit­ ten, so liegt ein Fehler im CAN-Baustein 6 vor.

Um eine hohe Aussagesicherheit zu erlangen, wird die Reset-Prozedur mehrmals in einer Schleife durchlaufen. Wird bei keinem Durchgang die Reset­ zeit RZ unterschritten, so erfolgt die Fehlermel­ dung. Fehler, die durch eine hardwaremäßige Falsch­ verdrahtung oder dergleichen auftreten, sollen hier selbstverständlich nicht betrachtet werden.

Gemäß Fig. 2 wird nach dem Start 10 im Schritt 11 zunächst ein Schleifenzähler geladen, damit die zu­ vor beschriebene Reset-Prozedur mehrmals durchge­ führt werden kann. Im nächsten Schritt 12 erfolgt dann das Resetieren des CAN-Bausteins 6. An­ schließend erfolgt das Laden eines Time-Out-Zählers (Schritt 13). Der Time-Out-Zähler definiert die Re­ setzeit RZ. Im Schritt 14 erfolgt die Abfrage, ob nach dem Resetieren des CAN-Bausteins 6 der Reset­ status innerhalb der Laufzeit des Time-Out-Zählers, also innerhalb der Resetzeit RZ gesetzt wurde. Ist dieses der Fall, so arbeitet der CAN-Baustein 6 fehlerfrei. Ist dies nicht der Fall, die Resetzeit RZ jedoch noch nicht abgelaufen, so erfolgt in einer Schleife 15 stets wieder eine Abfrage des Re­ setstatus′. Ist der Time-Out-Zähler abgelaufen (Schritt 16), so wird der Zustand des Schleifenzäh­ lers überprüft (Schritt 17). Ist der Zählerstand des Schleifenzählers noch kleiner als ein vorge­ gebener Wert, so wird eine Schleife 18 durchlaufen, das heißt, es erfolgt ein erneutes Resetieren des CAN-Bausteins 6. Es werden somit die bereits be­ schriebenen Schritte (ab Schritt 12) erneut durch­ laufen. Hat der Schleifenzähler einen vorgegebenen Wert erreicht (Schritt 17) und liegt kein gesetzter Resetstatus vor, so weist der CAN-Baustein 6 einen Fehler auf.

Das Flußdiagramm der Fig. 3 verdeutlicht die soft­ waremäßige Prüfung der Freigabe eines der CAN-Bau­ steine 6, nachdem ein Setzen (Zustand "1") zuvor stattgefunden hatte. Unter Freigabe ist somit die nach einem Reset erfolgende erneute Teilnahme am CAN-BUS 2 zu verstehen. Nach einem Zurücksetzen - "Wert 0" des Resetbefehls (Reset-Request; Control­ register: BIT 0) - wird geprüft, ob im Statusre­ gister 9 des entsprechenden CAN-Bausteins 6 nach einer bestimmten Zeit der Resetstatus durch den zu­ gehörigen Prozessor 7 (IMP) zurückgesetzt wird. Diese bestimmte Zeit hängt von den gleichen Fak­ toren ab, wie bei der zuvor beschriebenen software­ mäßigen Resetierbarkeit des CAN-Bausteins 6. Über­ steigt die Zeit eine Freigabezeit FZ, so liegt ein Fehler im CAN-Baustein 6 vor, so daß eine ent­ sprechende Fehlermeldung abgegeben wird. Auch hier ist vorgesehen, daß die Rücksetzprozedur in einer Schleife mehrmals durchlaufen wird.

Im einzelnen zeigt die Fig. 3 - ausgehend vom Start 19 - zunächst im Schritt 20 das Laden eines Schlei­ fenzählers. Im Schritt 21 erfolgt das Rücksetzen des Reset-Request. Nunmehr wird ein Time-Out-Zähler geladen, das heißt, es wird die Freigabezeit FZ ge­ startet (Schritt 22). Im Schritt 23 wird geprüft, ob - vor Ablauf der Freigabezeit FZ - der Resetstatus zurückgesetzt wird. Ist dieses innerhalb der Frei­ gabezeit FZ der Fall, so arbeitet der CAN-Baustein 6 einwandfrei. Ist die Freigabezeit FZ noch nicht abgelaufen und weist der Resetstatus noch den Wert "1" auf, so erfolgt in der Schleife 24 stets eine erneute Abfrage. Nach Ablauf der Freigabezeit FZ (Schritt 25), ohne daß eine Rücksetzung des Reset­ status stattgefunden hat, wird eine Schleife 26 des Schleifenzählers durchlaufen und bei jedem Durch­ lauf erneut die Prüfung vorgenommen. Ist der Schleifenzähler abgelaufen und liegt immer noch der Resetstatus "1" vor, so liegt ein Fehler im CAN- Baustein 6 vor.

Für eine Prüfung eines Zugriffsverbots der CPU beim Empfang einer Botschaft wird ebenfalls geprüft, ob hierbei eine bestimmte Zeit überschritten wird. Das Zugriffsverbot wird von dem zugehörigen Prozessor 7 (IMP) vorgegeben. Beim Zugriffsverbot ist ein CPU- Access des entsprechenden Kommunikationsobjekts "0"; "0" bedeutet "Verbot". Wird eine Zugriffsver­ botszeit ZZ überschritten, wobei diese vom Taktzy­ klus und dem inneren Zustand des zugehörigen CAN- Bausteins 6 abhängig ist, so liegt kein korrekter Betrieb des CAN-Bausteins 6 vor. Unter "inneren Zu­ stand" ist hier wiederum der Betriebszustand des CAN′s zu verstehen.

Das Flußdiagramm der Fig. 4 zeigt, daß nach dem Start 27 im Schritt 28 ein Zugriffsverbot vorliegt. Im Schritt 29 wird dann ein Time-Out-Zähler gela­ den, wodurch die Zugriffsverbotszeit ZZ gestartet wird. Im Schritt 30 wird nachfolgend geprüft, ob das Zugriffsverbot abgelaufen ist. Ist dieses nicht innerhalb des Time-Out (Zugriffsverbotszeit ZZ) der Fall (Schritt 31), so liegt ein Fehler vor.

Nachrichten, die von einem Teilnehmer 3 des Netz­ werks 1 ausgesendet werden, werden von den anderen Teilnehmern 3 als "empfangen" bestätigt. Die Folge ist, daß als korrekte Bestätigung der Transfersta­ tus gesetzt wird. Für eine Prüfung der korrekten Bestätigung bei vorhergehendem Zugriffsverbot der CPU ist also der Setzvorgang des Transferstatus ab­ zufragen. Die korrekte Bestätigung (Setzvorgang) des Transferstatus erfolgt durch den IMP des zuge­ hörigen CAN-Bausteins 6. Erfolgt nach einem erkann­ ten Zugriffsverbot der CPU durch den IMP (CPU-Ac­ cess = "0") kein Setzvorgang des Transferstatus des zugehörigen Discriptor-Bytes, so ist kein korrekter Betrieb des CAN-Bausteins 6 gegeben.

Das Flußdiagramm der Fig. 5 verdeutlicht die Prü­ fung. Nach dem Start 32 liegt im Schritt 33 ein Zu­ griffsverbot vor. Nach dem Aufheben des Zugriffs­ verbots (Schritt 34) erfolgt die Prüfung, ob der Transferstatus des zugehörigen Discriptors gesetzt ist (Schritt 35). Ist dies nicht der Fall, so liegt der beschriebene Fehler vor. Im nachfolgenden wird auf eine Überprüfung der korrekten Bestätigung (Transferstatus gesetzt) einer empfangenen Bot­ schaft (Data-Direktion = "0") in Abhängigkeit der Zeit zwischen zwei Nachrichten (mit gleichen Iden­ tifier) eingegangen. Hierzu sollen die Fig. 6a und 6b herangezogen werden. Läuft eine Nachricht über den CAN-BUS 2 in ein CAN-Baustein 6 eines Steuergeräts 4 ein, so wird dort der Transferstatus von dem zugehörigen IMP gesetzt. Die Zentraleinheit (CPU) des entsprechenden Steuergeräts 4 greift stets kurzfristig auf den Transferstatus zu, um die Daten der eingehenden Nachricht abzufragen. Gemäß Fig. 6b sollen zwei Nachrichten nacheinander ein­ gehen. Am Ende der ersten Nachricht wird der Trans­ ferstatus von dem IMP gesetzt (Pfeil 36). Wird et­ was später (Zeitpunkt t1) von der CPU eine Abfrage vorgenommen, so wird der Transferstatus (Pfeil 36) gelöscht und die Botschaft übernommen. Die Abfrage ist mit A gekennzeichnet. Bei einer weiteren Ab­ frage durch die CPU zum Zeitpunkt t2 kann von der CPU nichts übernommen werden, da die Abfrage ja be­ reits erfolgt ist und kein Transferstatus gesetzt wurde. Dieser beschriebene Zustand ist normal. Be­ trachtet man zum Zeitpunkt t3 eine Abfrage, die nach dem Setzen des Transferstatus (Pfeil 36) das erste Mal erfolgt, so erfolgt eine Löschung des Transferstatus und eine Abfrage der Botschaft. Wird kurze Zeit später (Zeitpunkt t4) wiederum von der CPU eine Abgefrage durchgeführt, so erfolgt eine Löschung des zuvor aufgrund der zweiten Nachricht gesetzten Transferstatus′ (Pfeil 36′) und es werden die entsprechenden Daten abgefragt. Auch dieser Zu­ stand ist normal, das heißt, die einzelnen Systeme arbeiten einwandfrei. Erfolgt jedoch nunmehr wie­ derum eine Anfrage der CPU zum Zeitpunkt t5, wobei die Zeiten zwischen den Abfragen stets gleich groß sein sollen (die Zeit zwischen t3 und t4 ist ebenso groß wie zwischen t4 und t5), so ergibt sich im Zu­ sammenhang mit den Zeiten zwischen den Nachrichten und den jeweiligen Sendezeiten TS (Länge der Nach­ richten), daß hier (zum Zeitpunkt t5) der Transfer­ status von dem IMP nicht gesetzt sein kann. Sollte hier doch ein gesetzter Transferstatus vorliegen, so ist ein Fehler gegeben; ein korrekter Betrieb ist nicht sichergestellt.

In der Fig. 6a wird die Prüfung nochmals anhand des dort wiedergegebenen Flußdiagramms erläutert. Nach dem Start 36 wird zunächst im Schritt 37 ein Schleifenzähler geladen und nachfolgend im Schritt 38 der Transferstatus aufgrund einer Empfangsbot­ schaft gesetzt. Durch Anfrage der CPU wird im Schritt 39 eine Löschung des Transferstatus vorge­ nommen. Im Schritt 40 erfolgt dann die Prüfung, ob der Zählerstand des Schleifenzählers kleiner als die Anzahl von durchlaufenen Schleifen 41 ist. Da bei einer Abfrage der CPU lediglich - wie vorstehend ausgeführt - zweimal hintereinander auf einen ge­ setzten Transferstatus gestoßen werden darf, ist dem Schleifenzähler der Wert "2" vorzugeben. Die Anzahl der durchlaufenden Schleifen 41 darf demzu­ folge nicht größer als der Wert "2" sein. Wird die Schleifendurchlaufszahl größer als 2, so liegt der beschriebene Fehler vor.

Nunmehr erfolgt eine Überprüfung im Hinblick auf eine korrekte Bestätigung (Transferstatus gesetzt) einer gesendeten Botschaft. Sofern ein Teilnehmer 3 eine Nachricht sendet und diese von einem anderen Teilnehmer 3 korrekt empfangen wurde, so wird dieses dem sendenden Teilnehmer 3 bestätigt; sein Transferstatus wird gesetzt. Erfolgt kein Setzen des Transferstatus, so wird die Sendung laufend wiederholt. Bei jedem Sendezyklus wird eine Er­ höhung des Zählerstandes eines Fehlerzählers vorge­ nommen. Überschreitet der Zählerstand des Fehler­ zählers einen vorgegebenen Fehlerzählstand FS so wird ein Errorstatus gesetzt (Errorstatus = "1"). Eine Fehlermeldung erfolgt, wenn bei Nichtvorlage des Resetstatus nach einer zuvor gesendeten Nach­ richt der Transferstatus nicht gesetzt wird und gleichzeitig auch kein Errorstatus vorliegt, obwohl - wie üblich - eine Vielzahl von Sendungen abgegeben wurde, so daß eigentlich der Errorstatus vorliegen müßte. Dabei muß sichergestellt sein, daß kein Re­ setstatus vorliegt.

Die Fig. 7 verdeutlicht diesen Vorgang. Nach dem Start 42 wird eine Nachricht gesendet (Schritt 43), wobei das Senden aufgrund ausbleibender Bestätigung in einer Zeitschleife (Schritt 44) derart oft wie­ derholt wird, daß sowohl der Transferstatus als auch der Errorstatus gesetzt sein müßten (Schritte 45 und 46). Liegt gemäß Schritt 47 auch kein Reset­ status vor, so ist kein korrekter Betrieb gegeben.

Die folgenden softwaremäßigen Fehlererkennungsver­ fahren betreffen den CAN-BUS 2. Dieser soll auf Ka­ belbruch untersucht werden. Hat ein BUS-Teilnehmer 3 keine Verbindung mehr zu irgend einem weiteren Teilnehmer 3, so bekommt der sendende Teilnehmer keine Bestätigung auf seine Sendungen. Dieses führt - wie zuvor beschrieben - zur Erhöhung des Zähler­ standes des Fehlerzählers. Dabei wird der Fehler­ zählstand FS überschritten. Der Errorstatus wird von dem IMP gesetzt. Erfolgt nun eine weitere Erhö­ hung des Zählerstandes des Fehlerzählers, so wird beim Überschreiten eines vorgegebenen Zählerstandes (BUS-Zählstand) ein BUS-Status gesetzt. Liegt ein Errorstatus vor, wird der BUS-Status jedoch nicht gesetzt, so ist dieses - unter Berücksichtigung eines nicht gesetzten Transferstatus - ein Zeichen dafür, daß eine Kommunikation aufgrund eines Kabel­ fehlers verhindert ist.

Nach dem Start 48 im Flußdiagramm der Fig. 8 wird im Schritt 49 eine Botschaft gesendet, wobei das Senden automatisch von der IMP wiederholt wird, falls keine Bestätigung der Nachricht vorliegt. Es erfolgt kein Setzen des Transferstatus (Schritt 51), jedoch wird nach einer entsprechenden Anzahl von Sendungen der Errorstatus gesetzt (Schritt 52). Trotz weiterer Sendungen wird der BUS-Status (Schritt 53) nicht gesetzt, so daß von einem Kabel­ fehler auszugehen ist.

Eine Überprüfung des CAN-BUSSES 2 im Hinblick auf Kabelfehler kann zwischen allen Teilnehmern 3 da­ durch erfolgen, daß eine Auswertung des Transfer­ status der zu empfangenden Botschaften unter Be­ rücksichtigung des Wissens über die BUS-Kabelfüh­ rung (Teilnehmer-Anordnung) erfolgt. Eine Kabel­ unterbrechung läßt sich durch einen korrekt ar­ beitenden Teilnehmer 3 aufgrund der Auswertung seines Transferstatus lokalisieren.

Schließlich kann eine Überprüfung des CAN-BUSSES 2 auf Kurzschluß erfolgen. Der CAN-BUS 2 weist drei Leiter auf, und zwar CANL, CANH und Masse. Es kann nunmehr auf einen Kurzschluß zwischen CANL und Ver­ sorgungsspannung und/oder zwischen CANH und Masse und/oder zwischen CANL und CANH untersucht werden.

Finden innerhalb einer Zeitspanne mehrmalige BUS- Off's statt und ist ein Fehlverhalten eines CAN- Bausteins - aufgrund der zuvor beschriebenen Prü­ fung - ausgeschlossen, so liegt ein Kurzschluß der oben genannten Arten vor.

Das zuvor Beschriebene soll anhand des Flußdia­ gramms der Fig. 9 nochmals verdeutlicht werden. Nach dem Start 54 erfolgt im Schritt 55 das Laden eines Schleifenzählers. Dieser wird beispielsweise auf den Wert 0 gesetzt. Im Folgeschritt 56 wird ge­ prüft, ob ein BUS-Off vorliegt. Liegt er vor, so erfolgt im Schritt 57 eine Prüfung daraufhin, ob die Software einwandfrei arbeitet und insbesondere wird der Zugriff auf den BUS wieder freigegeben. Im Schritt 58 wird dann ein Timer gestartet. Ist die Timerzeit abgelaufen, so wird die Prüfung unter­ brochen. Wird jedoch innerhalb der Laufzeit des Ti­ mers erneut ein BUS-Off erkannt (Schritt 59) so wird der Timer 60 gestoppt und die zwischen dem Start und dem Stoppen des Timers vergangene Zeit ermittelt, die im Schritt 61 mit einer Schwelle a verglichen wird. Ist die Zeit kleiner als die Schwelle a, so wird im Schritt 63 der Schleifenzäh­ ler um "1" erhöht und gleichzeitig erfolgt eine Prüfung, ob der Wert des Schleifenzählers kleiner als eine vorgegebene Schwelle b ist. Ist der Schleifenzähler kleiner als die Schwelle b, so wird die Schleife 62 erneut durchlaufen und wiederum eine BUS-Off-Erkennung durchgeführt, nachdem der BUS-Baustein durch die zugehörige CPU des Steuerge­ rätes wieder in den Zustand versetzt wurde, am BUS teilzunehmen (sende- und/oder empfangsfähig). Durch die Schritte 58 und 60 ist erkennbar, ob ein BUS- Off innerhalb kurzer Zeit auftritt. Erfolgt dieses sehr oft hintereinander, nämlich häufiger als die vorgegebene Schwelle b, so liegt der Kabelfehler vor.

Claims (23)

1. Verfahren zur Fehlererkennung und/oder Fehlerlo­ kalisation bei Datenübertragungen über ein Netz­ werk, dadurch gekennzeichnet, daß nach Abgabe eines Signals eine Prüfung erfolgt, ob innerhalb einer vorgegebenen Zeit eine auf dem Signal beruhende Zu­ standsänderung eintritt und daß beim Ausbleiben der Zustandsänderung eine Fehlermeldung erfolgt.

2. Verfahren nach Anspruch 1, dadurch gekennzeich­ net, daß das Netzwerk (1) als serieller BUS (2) eines Kraftfahrzeugs ausgebildet ist, an dem meh­ rere Teilnehmer (3) angeschlossen sind.

3. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß die Teilnehmer (3) Steuergeräte (4) des Kraftfahrzeugs sind, die je­ weils eine Zentraleinheit (5; CPU) und einen BUS- Baustein (6) aufweisen, der einen Prozessor (7; IMP = Interface-Management-Prozessor) besitzt.

4. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß jeder BUS-Baustein (6) mit dem seriellen BUS (2) verbunden ist.

5. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß jeder BUS-Baustein (6) ein Controlregister (8) und ein Statusregister (9) besitzt.

6. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß nach dem Ausblei­ ben einer Zustandsänderung das Signal mindestens noch ein weiteres Mal abgegeben wird.

7. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß die Abgabe der Signale mittels einer Programmschleife ge­ steuert/wiederholt wird.

8. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß zur Prüfung einer Resetierbarkeit des BUS-Bausteins (6) das Signal ein von der Zentraleinheit (CPU) eines der Steuer­ geräte (4) gesetzter Resetbefehl (RB) zum Setzen eines Resetstatus im Statusregister (9) des BUS- Bausteins (6) ist.

9. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß die vorgegebene Zeit eine Resetzeit (RZ) ist und in Abhängigkeit von einem Taktzyklus des BUS-Bausteins (6) und/oder einem Taktzyklus der in ansprechenden Zentralein­ heit (CPU: Microcontroller oder Microcomputer) und/oder dem jeweiligen Betriebszustand des BUS- Bausteins (Statusregister-Zustand) festgelegt wird.

10. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß ein Fehler des BUS-Bausteins (6) gemeldet wird, wenn innerhalb der Resetzeit kein Resetstatus vorliegt.

11. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß nach einem Reset­ befehl geprüft wird, ob innerhalb einer Freigabe­ zeit (FZ) der Resetstatus durch den Prozessor (7; IMP) wieder aufgehoben wird.

12. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß die Freigabezeit (FZ) von dem Taktzyklus des BUS-Bausteins (6) und/oder dem Taktzyklus der Zentraleinheit (CPU) und/oder dem jeweiligen Betriebszustand (Statusre­ gister-Zustand) des BUS-Bausteins (6) festgelegt wird.

13. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß ein während des Empfangs einer Botschaft vorliegenden, von dem Pro­ zessor (IMP) vorgegebenen Zugriffsverbots der Zen­ traleinheit (CPU) eine Zugriffsverbotszeit (ZZ) nicht überschritten wird.

14. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß die Zugriffsver­ botszeit (ZZ) von dem Taktzyklus und/oder dem je­ weiligen Betriebszustand (Statusregister-Zustand) des BUS-Bausteins (6) abhängig ist.

15. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß eine Prüfung er­ folgt, ob nach einem Zugriffsverbot der Zentralein­ heit (5) ein Setzvorgang eines Transferstatus eines dem entsprechenden Kommunikationsobjekt zugehörigen Discriptor-Bytes durchgeführt wird.

16. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß nach jeder über den seriellen BUS (2) empfangenen Nachricht von dem Prozessor (IMP) der Transferstatus gesetzt wird und daß bei der von der Zentraleinheit (CPU) erfolgen­ den Abfrage der Nachricht der Transferstatus ge­ löscht und eine Botschaft der Nachricht übernommen wird.

17. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß eine Prüfung er­ folgt, ob höchstens zwei innerhalb einer Abfrage­ zeit von der Zentraleinheit (CPU) aufeinanderfol­ genden Abfragen ein Transferstatus vorliegt, wobei die Abfragezeit kleiner als die Hälfte der minima­ len Zeit zwischen zwei aufeinanderfolgenden Nach­ richten (Nachrichtenanfängen oder Nachrichtenenden) ist.

18. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß der Empfang einer von einem BUS-Teilnehmer (3) gesendeten Nachricht durch einen anderen BUS-Teilnehmer (3) bestätigt wird, wobei beim Ausbleiben der Empfangsbestätigung stets wieder erneut gesendet und der Zählerstand eines Fehlerzählers jeweils erhöht wird und daß beim Überschreiten eines Fehlerzählstands (FS) ein Errorstatus im BUS-Baustein (6) gesetzt wird.

19. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß eine Fehlermeldung erfolgt, wenn bei Nichtvorlage des Resetstatus nach einer zuvor gesendeten Nachricht der Transferstatus nicht gesetzt wird und gleichzeitig auch kein Errorstatus vorliegt.

20. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß beim Ausbleiben der Empfangsbestätigung aufgrund einer gesendeten Nachricht stets erneut gesendet und der Zählerstand des Fehlerzählers erhöht wird, wobei zunächst beim Erreichen des Fehlerzählstandes (FS) der Errorsta­ tus von dem Prozessor (IMP) gesetzt wird und nach weiteren, unbestätigten Sendungen ein BUS-Zählstand erreicht wird, der einen gesetzten BUS-Status (BUS- OFF) zur Folge hat.

21. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß beim Vorliegen des Fehlerzählstandes (FS) und nicht Vorliegen des BUS- Zählstandes sowie des Transferstatus eine BUS-Ka­ belbruch-Fehlermeldung erfolgt.

22. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß eine Lokalisation eines Fehlers der BUS-Verbindung zwischen mehreren BUS-Teilnehmern (3) dadurch erfolgt, daß an einem BUS-Teilnehmer (3) der jedem anderen Teilnehmer (3) zugeordnete Transferstatus überprüft wird.

23. Verfahren nach einem der vorhergehenden Ansprü­ che, dadurch gekennzeichnet, daß eine Kurzschluß­ fehlermeldung der BUS-Verbindung erfolgt, wenn in­ nerhalb einer Zeitspanne mehrmals ein gesetzter BUS-Status vorliegt, wobei nach erkanntem BUS-OFF der Bus-Baustein (6) von der Zentraleinheit (CPU) in den Zustand versetzt wird, wieder am BUS teilzu­ nehmen (Nachrichten zu empfangen und/oder zu sen­ den).