DE112012006879T5

DE112012006879T5 - Neuer Ansatz zum Handhaben eines Controller-Area-Network Bus-Off

Info

Publication number: DE112012006879T5
Application number: DE112012006879.3T
Authority: DE
Inventors: Michael A. Sowa; Shengbing Jiang; Katrina M. Schultz; Mutasim A. Salman
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2012-09-05
Filing date: 2012-09-05
Publication date: 2015-05-21
Anticipated expiration: 2032-09-06
Also published as: US20150220401A1; WO2014039035A1; CN104782082A; CN104782082B; DE112012006879B4; US9600372B2

Abstract

Ein System und ein Verfahren zum Bestimmen, wann ein Controller in Antwort auf einen Bus-Off Zustand zurückzusetzen ist. Das Verfahren weist ein Bestimmen, dass der Controller in einen ersten Bus-Off Zustand eingetreten ist, und ein sofortiges Zurücksetzen des Controllers auf. Das Verfahren weist ferner ein Setzen eines Rest-Timers in Antwort darauf, dass der Controller zurückgesetzt ist, auf, ein Bestimmen, ob der Controller in einen nachfolgen Bus-Off Zustand eingetreten ist, und ein Bestimmen einer Reset-Zeit. Das Verfahren setzt den Controller in Antwort auf den nachfolgenden Bus-Off Zustand sofort zurück, falls die Reset-Zeit größer als das ein erstes vorbestimmtes Zeitintervall ist, und setzt den Controller in Antwort auf den nachfolgenden Bus-Off Zustand zurück, nachdem ein zweites vorbestimmtes Zeitintervall abgelaufen ist, falls die Rest-Zeit kleiner als das erste vorbestimmte Zeitintervall ist.

Description

Hintergrund der Erfindung
Gebiet der Erfindung
Diese Erfindung bezieht sich im Allgemeinen auf ein System und ein Verfahren zum Zurücksetzen beziehungsweise Resetten eines Controllers in Antwort auf einen Controller-Area-Network (CAN) Bus-Off Zustand, und insbesondere auf ein System und ein Verfahren zum Zurücksetzen beziehungsweise Resetten eines elektronischen Steuergeräts (ECU) in einem Fahrzeug in Antwort auf einen CAN-Controller Bus-Off Zustand, das ein Unterscheiden zwischen internen ECU Fehlern und zufälligen äußeren Störungen umfasst.
Diskussion des Standes der Technik
Die meisten modernen Fahrzeuge umfassen viele elektronische Steuergeräte (ECUs) oder Controller, welche den Betrieb von verschiedenen Fahrzeugsystemen, wie beispielsweise einem Antriebssystem, einer Klimaanlage, einem Infotainmentsystem, einer Karosseriesteuerung, einem Fahrwerksystem, und so weiter steuern. Derartige Controller und ECUs unterliegen einem bestimmten Verwendungszweck und benötigen speziell entwickelte Software, welche diesen ermöglichen ihre Steuerungsfunktion wahrzunehmen. Viele oder alle der einem jeweiligen Fahrzeugsystem zugeordneten ECUs sind typischerweise Teil eines verteilten Controller-Area-Network (CAN), welches einen mit den einzelnen ECUs in elektrischer Verbindung stehenden CAN-Bus verwendet, der die Übertragung von Nachrichten zwischen den ECUs ermöglicht. Jedes ECU umfasst eine als CAN-Controller bekannte Hardwareschaltung, die die Übertragung von Nachrichten auf den CAN-Bus sowie den Empfang von Nachrichten von dem CAN-Bus steuert. Der CAN-Controller liefert Signale für eine Host-Anwendungsschicht auf dem ECU, die die Software zum Betreiben des ECU für den jeweiligen Zweck umfasst.
Fehlermeldungen treten auf, wenn der CAN-Controller feststellt, dass die Nachricht ein unzulässiges Kopfformat oder eine andere unzulässige Konfiguration aufweist. Fehler können als Resultat von zufälligen äußeren Störungen, wie beispielsweise EMI Impulsen, oder internen Controller Störungen, auftreten. Falls der Controller in einem ECU eine Nachricht von dem CAN-Bus erhält und feststellt, dass die Nachricht einen Fehler aufweist, kann dieser CAN Controller die Nachricht zerstören um diese für andere, mit dem Bus gekoppelte ECUs unbrauchbar zu machen. Falls ein fehlerhafter CAN-Controller unzulässigerweise eine Nachricht zerstört, da er annimmt, dass diese einen Fehler aufweist, obwohl dies nicht so ist, können die anderen ECUs in dem CAN Netzwerk diese Nachricht zu dem Zeitpunkt, zu dem sie diese verwenden sollten, nicht mehr verwenden.
Jeder CAN-Controller in einem CAN Netzwerk arbeitet typischerweise in einem von drei Zuständen, nämlich in einem fehleraktiven Zustand, in einem fehlerpassiven Zustand, oder einem Bus-Off Zustand. Falls sich ein CAN-Controller in seinem aktiven Modus oder seinem fehleraktiven Zustand befindet und Nachrichten an den CAN-Bus liefert sowie Nachrichten von dem CAN-Bus empfängt, können Fehler in der oben beschriebenen Form dort auftreten, wo die Übertragung von Nachrichten auf oder der Empfang von Nachrichten von dem Bus fehlgeschlagen ist. Der CAN-Controller kann eine Fehlerzustandsmarke auf den Bus schicken, um andere Nachrichten auf dem Bus wie oben erwähnt zu zerstören. Der CAN-Controller akkumuliert die Fehler über die Zeit und kann in den fehlerpassiven Zustand eintreten, falls die Anzahl von Fehlern für den Empfang von Nachrichten, die von einem Empfangsfehlerzähler (REC) in dem CAN-Controller akkumuliert wurden, oder falls die Anzahl von Fehlern für die Übertragung von Nachrichten, die von einem Übertragungsfehlerzähler (TEC) in dem CAN-Controller akkumuliert wurden, einen vorbestimmten Wert erreicht, wie beispielsweise 127. Während des fehlerpassiven Zustands kann der TEC fortfahren, Übertragungsfehler zu akkumulieren, wobei der CAN-Controller in einen Bus-Off Zustand eintritt und von dem CAN-Bus abgetrennt wird, sobald ein zweiter Zählerwert erreicht ist, wie beispielsweise 255. Folglich kann der CAN-Controller, durch überführen des CAN-Controllers in den fehlerpassive Zustand sobald dieser eine vorbestimmte Anzahl von Fehlern akkumuliert hat, von dem Zerstören von Nachrichten, die ansonsten für andere ECUs in dem Netzwerk gültig wären, abgehalten werden, und der CAN-Controller wird anschließend, sobald die Übertragung von Fehlern einen anderen vorbestimmten Wert erreicht, daran gehindert, Fehlermeldungen auf den Bus zu übertragen, die ansonsten durch andere ECUs in dem Netzwerk bearbeitet werden würden.
Der CAN-Controller benachrichtigt die Anwendungsschicht, sobald der Bus-Off Zustand eintritt. Die Anwendungsschicht ist mit einem bestimmten Protokoll programmiert, das es dieser erlaubt, den CAN-Controller nach Auftreten eines Bus-Off Zustands zurückzusetzen, so dass der CAN-Controller erneut aktiv werden kann, um Nachrichten auf dem CAN-Bus zu senden und zu empfangen. Folglich kann der CAN-Controller in dem Bus-Off Zustand verbleiben, bis die Anwendungsschicht ein Zurücksetzen des CAN-Controllers in den fehleraktiven Zustand initiiert. Verschiedene CAN Netzwerke verwenden verschiedene Typen von Bus-Off Resetstrategien, um zu bestimmen, wie und wann die Anwendungsschicht den CAN-Controller zurücksetzt.
Bei einer bekannten Bus-Off Resetstrategie, auf welche als Autoresetstrategie Bezug genommen wird, initiiert die Anwendungsschicht das Reset des CAN-Controllers unmittelbar nachdem der CAN-Controller in den Bus-Off Zustand getreten ist, und der Can-Controller kehrt unmittelbar nachdem der CAN-Controller eine vorbestimmte Anzahl von Malen ein vorbestimmte Anzahl vorn rezessiven Bits empfängt, wie beispielsweise 11 mal 128 rezessive Bits, in den fehleraktiven Zustand zurück. Jedoch würde, falls der CAN-Controller selber fehlerhaft ist und die Anwendungsschicht diesen sofort zurücksetzt, der CAN-Controller die normale Fahrzeugsteuerung wiederholt unterbrechen.
Bei einer weiteren bekannten Bus-Off Resetstrategie, auf die als Warte-dann-Reset Strategie Bezug genommen wird, wird die Anwendungsschicht eine gewisse Zeitspanne nachdem Auftreten des Bus-Off Zustands warten, um dem CAN-Controller Zeit zu geben, sich nach dem Fehlerzustand wiederherzustellen. Jedoch gibt es, wie erwähnt, einige durch äußere Beeinträchtigungen, wie beispielsweise elektromagnetischer Strahlung, verursachte CAN-Controller Fehlerzustände, die zufällig und periodisch sind und nicht allzu lange anhalten. Falls die Bus-Off Resetstrategie ist, abzuwarten, und dann den CAN-Controller in den fehleraktiven Zustand zurückzusetzen, und die Ursache des Fehlers eine äußere Störung ist, dann wird der CAN-Controller für eine gewisse Zeitdauer offline sein, zu der die Beeinträchtigung wahrscheinlich noch keine Probleme verursacht. Während dieser Zeitdauer wird der spezielle CAN-Controller nicht fähig sein, Nachrichten auf den Bus zu geben, welche möglicherweise den Fahrzeugbetrieb oder Fahrzeugleistung beeinflussen. Deshalb kann ein CAN-Controller, der auf eine Nachricht eines anderen, sich in der Wartezeit für eine Bus-Off Resetstrategie befindenden CAN-Controller wartet, einen Diagnose-Fehlercode (DTC) auslösen, der angibt, dass der CAN-Controller zum Verschicken von Nachrichten nicht verfügbar ist.
Bei einer anderen bekannten Bus-Off Resetstrategie, auf die als Frequenzlimitierende Resetstrategie Bezug genommen wird, ist es erforderlich, dass eine Zeitspanne zwischen jeweils zwei aufeinanderfolgenden Resets länger als ein vorbestimmtes Zeitintervall ist. Für diesen Fall setzt die Anwendungsschicht den CAN-Controller sofort zurück, falls ein zweiter Bus-Off Zustand nach dem vorbestimmten Zeitintervall ab dem Reset des ersten Bus-Off Zustands auftritt. Jedoch würde bei einem fehlerhaften Controller ein zu kleines Zeitintervall zwischen den Resets in einem sofortigen Zurücksetzen des CAN-Controllers bei einem Bus-Off Zustand resultieren, und der CAN-Controller würde keine Zeit haben, sich nach dem Fehlerzustand wiederherzustellen, was in kontinuierlichen Beeinträchtigungen der normalen Kommunikation über den Bus resultieren würde, und es würde ein zu langes Zeitintervall in einer unnötigen Unterbrechung des CAN-Controllers, bei der dieser nicht mit dem Bus verbunden ist, resultieren. Untersuchungen haben ergeben, dass kein geeignetes Zeitintervall zwischen einem Bus-Off Zustand und einem Reset die obigen Situationen zufriedenstellend lösen kann.
In Übereinstimmung mit den Lehren der vorliegenden Erfindung werden ein System und ein Verfahren zum Bestimmen, wann ein Controller in Antwort auf einen Bus-Off Zustand zurückzusetzen ist, der als Resultat von Fehlern auftritt, die in Nachrichten identifiziert werden, die über einen Controller-Area-Network (CAN)-Bus übertragen werden oder aus einem Controller-Area-Network (CAN)-Bus empfangen werden, wobei der Bus-Off Zustand bewirkt, dass der Controller von dem CAN-Bus getrennt wird. Das Verfahren umfasst ein Bestimmen, dass der Controller in einen ersten Bus-Off Zustand eingetreten ist, und ein sofortiges Zurücksetzen des Controllers in Antwort auf das Bestimmen, dass der Controller in den ersten Bus-Off Zustand eingetreten ist. Das Verfahren weist ferner ein Setzen eines Reset-Timers in Antwort darauf auf, dass der Controller zurückgesetzt ist, und ein Bestimmen, ob der Controller in einen nachfolgenden Bus-Off Zustand eingetreten ist, nachdem der Controller zurückgesetzt worden ist, und ein Bestimmen, ob eine Reset-Zeit von einer Zeit, von wann der Controller zurückgesetzt ist bis zu dem nachfolgenden Bus-Off Zustand, größer ist als ein erstes vorbestimmtes Zeitinterfall. Das Verfahren setzt den Controller in in Antwort auf den nachfolgenden Bus-Off Zustand sofort zurück, falls die Reset-Zeit größer als das erste vorbestimmte Zeitintervall ist, und setzt den Controller in Antwort auf den nachfolgenden Bus-Off Zustand zurück, nachdem ein zweites vorbestimmtes Zeitintervall abgelaufen ist, falls die Reset-Zeit kleiner als das erste vorbestimmte Zeitintervall ist.
Zusätzliche Merkmale der vorliegenden Erfindung werden aus der folgenden Beschreibung und den beigefügten Ansprüchen, in Verbindung mit den begleitenden Zeichnungen betrachtet, ersichtlich.
Kurze Beschreibung der Zeichnungen
1 ist eine Darstellung einer Vielzahl von mit einem CAN-Bus gekoppelten ECUs;
2 ist ein Zustandsdiagramm, das die Zustände eines CAN-Bus Controllers in den in 1 gezeigten ECUs zeigt;
3 ist ein Zeitdiagramm, das eine erste Lösung einer Bus-Off Resetstrategie zeigt;
4 ist ein Zeitdiagramm, das eine zweite Lösung für eine Bus-Off Resetstrategie zeigt;
5 ist ein Flussdiagramm, das einen Prozess zum Implementieren der in 3 dargestellten Bus-Off Resetstrategie zeigt; und
6 ist ein Flussdiagramm, das einen Prozess zum Implementieren der in 4 dargestellten Bus-Off Resetstrategie zeigt.
Ausführliche Beschreibung der Ausführungsformen
Die folgende Diskussion von Ausführungsformen der auf ein System und ein Verfahren zum Bestimmen einer CAN-Controller Bus-Off Resetstrategie gerichteten Erfindung sind lediglich beispielhafter Natur, und ist keineswegs dazu vorgesehen, die Erfindung oder deren Anwendungen und Verwendungen zu beschränken. Zum Beispiel hat die vorliegende Erfindung eine Anwendung bei Zurücksetzen von CAN-Bus-Controllern in ECUs, die mit einem Fahrzeug assoziiert sind. Jedoch wird ein Fachmann würdigen, dass die Erfindung auch bei anderen Controllern Anwendung findet.
1 ist eine Darstellung eines CAN-Netzwerks 10, das eine Vielzahl von mit einem CAN-Bus 14 gekoppelten ECUs 12 aufweist. Das CAN-Netzwerk 10 ist dazu vorgesehen, allgemein irgendein CAN-Netzwerk in einem Fahrzeug zu repräsentieren, das irgendeine Anzahl von ECUs für irgendein geeignetes Fahrzeugsystem aufweist. Nachrichten, die durch eine bestimmte ECU 12 übertragen oder empfangen werden, werden auf dem Bus 14 bereitgestellt, um durch eine andere ECU 12 in dem Netzwerk 10 auf eine Art und Weise empfangen und behandelt zu werden, die von einem Fachmann gut verstanden wird. Wie oben diskutiert, weist jedes ECU 12 einen Hardwarechip auf, der als ein CAN-Controller 16 bezeichnet wird, der die Übertragung von Nachrichten auf den CAN-Bus 14 und den Empfang von Nachrichten aus dem CAN-Bus 14 steuert. Der CAN-Controller 16 stellt Signale zu einer Host-Anwendungsschicht 18 auf der ECU 12 bereit, die die Software aufweist, die das ECU 12 für den speziellen Zweck betreibt. Wenn der CAN-Controller 16 in einen Bus-Off Zustand eintritt, benachrichtigt er die Host-Anwendungsschicht 18 von dieser Bedingung.
2 ist eine Darstellung eines CAN-Controller-Zustandsdiagramms 20, das die oben bezeichneten CAN-Controller Zustände zeigt. Insbesondere zeigt das Zustandsdiagramm 29 einen fehleraktiven Zustand 22, einen fehlerpassiven Zustand 24, und einen Bus-Off Zustand 26.
Die vorliegende Erfindung schlägt eine Bus-Off Resetstrategie vor, die effektiv zwischen Fehlern unterscheidet, die durch äußere zufällige Störungen verursacht werden, und Fehlern, die durch interne Controller-Fehler verursacht werden. Eine Analyse hat gezeigt, dass ein durch einen internen Controller-Fehler verursachter Bus-Off Zustand schnell erreicht wird, zum Beispiel in weniger als 1 Sekunde, das heißt, der TEC erreicht den vorbestimmten Fehler-Zählerstand ausgehend von TEC = 0 nach einem Reset zu dem fehleraktiven Zustand 22, und ein Bus-Off Zustand, der durch eine äußere zufällige Störung verursacht wird, wird langsamer erreicht, zum Beispiel in mehr als 100 Sekunden. Um diese Unterscheidung bereitzustellen, betrachtet die vorliegende Erfindung die Zeit von einem ersten Bus-Off Zustand bis zu einem nächsten Bus-Off Zustand, und falls diese Zeit größer als ein vorbestimmte kalibrierbares Zeitintervall ist, bestimmt der CAN-Controller, dass die Fehler durch eine äußere Störung verursacht werden, und falls diese Zeit kleiner oder gleich dem Zeitintervall ist, bestimmt der CAN-Controller, dass die Fehler durch einen internen Controller-Fehler verursacht werden. Wie hier diskutiert, falls der Bus-Off Zustand durch einen internen Controller-Fehler verursacht wird, dann ist einiges an Resetzeit erwünscht, um dem CAN-Controller 16 die Gelegenheit zu geben, sich von dem Fehler zu erholen. Falls jedoch der Bus-Off Zustand durch äußere Störungen verursacht wird, dann ist diese Störung typischerweise sehr schnell, und der CAN-Controller 16 kann sofort zurückgesetzt werden.
Für den Fall, dass der Bus-Off Zustand durch einen internen Controller-Fehler verursacht wird, hat sich gezeigt, dass die Zeit von einem Bus-Off Zustand Reset, TEC = 0, bis zu dem nächsten Bus-Off Zustand 26, für einen schnellen CAN-Controller, zum Beispiel 500 Kb/s, kleiner als 10 Sekunden ist, wenn die Rahmen-Fehlerrate größer als 0,12 ist, und kleiner eine 1 Sekunde ist, wenn die Rahmen-Fehlerrate größer als 0,21 ist. Es hat sich auch gezeigt, dass die Zeit von einem Bus-Off Zustand, TEC = 0, bis zu dem nächsten Bus-Off Zustand 26, für einen langsamen CAN-Controller, zum Beispiel 33,3 Kb/s, kleiner als 10 Sekunden ist, wenn die Rahmen-Fehlerrate größer als 0,25 ist, und kleiner als 1 Sekunde, wenn die Rahmen-Fehlerrate größer als 0,7 ist.
Für durch äußere Störungen verursachte Bus-Off Zustände in einem schnellen CAN-Controller hat es sich gezeigt, dass die Zeit von einem Bus-Off Zustand Reset bis zu dem nächsten Bus-Off Zustand 26 in einer rauen EMI (elektromagnetische Störungen) Umgebung mehr als 1300 Sekunden beträgt, einschließlich einer Bitfehlerrate von 10³. Für einen langsamen CAN-Controller beträgt die Zeit von einem Bus-Off Zustand Reset bis zu dem nächsten Bus-Off Zustand 26 in einer rauen EMI Umgebung mehr als 19000 Sekunden.
Die oben angegeben Werte gelten für die Zeit von wann der CAN-Controller 16 in den fehleraktiven Zustand 22 eintritt bis zu wenn er in den Bus-Off Zustand 26 eintritt. Für diese CAN-Controller, die auch den fehlerpassiven Zustand 24 benutzen, können von der Zeit zwischen wenn der CAN-Controller 16 in den fehlerpassiven Zustand 22 eintritt bis wenn er in den Bus-Off Zustand 26 eintritt dieselben Werte berechnet werden. Insbesondere für Bus-Off Zustände, die durch einen internen Controller-Fehler verursacht werden, hat es sich gezeigt, dass für einen schnellen CAN-Controller die Zeit zwischen wenn der Controller 16 in den fehlerpassiven Zustand eintritt bis wenn er in den Bus-Off Zustand eintritt typischerweise kleiner als 10 Sekunden ist, wenn die Rahmenfehlerrate größer als 0,11 Sekunden ist, und kleiner als 1 Sekunde ist, wenn die Rahmenfehlerrate größer als 0,16 ist. Für langsame CAN-Controller hat es sich gezeigt, dass die Zeit zwischen wenn der Controller 16 in den fehlerpassiven Zustand 24 eintritt bis wenn er in den Bus-Off Zustand 26 eintritt, kleiner als 10 Sekunden ist, wenn die Rahmenfehlerrate größer als 0,18 Sekunden ist, und kleiner als 1 Sekunde ist, wenn die Rahmen-Fehlerrate größer als 0,55 ist.
Für Bus-Off Zustände, die durch äußere Störungen verursacht werden, hat es sich gezeigt, das für einen schnellen CAN-Controller die Zeit zwischen wenn der Controller 16 in den fehlerpassiven Zustand 24 eintritt bis wenn er in den Bus-Off Zustand 26 eintritt in einer rauen EMI Umgebung typischerweise größer als 35 Sekunden ist, und für eine langsamen CAN-Controller in einer rauen EMI Umgebung typischer größer als 510 Sekunden ist.
Wenn basierend auf dem Vorhergehenden der Bus-Off Zustand 26 in dem CAN-Controller 16 als ein Resultat der Akkumulation von Fehlern wie oben beschrieben auftritt, berichtet der CAN-Controller 16 den Bus-Off Zustand 26 an die Anwendungsschicht 18, welche in eine Unterbrechungsroutine übergeht, die ein Starten eines Timers einschließt, um zu bestimmen, wann der nächste Bus-Off Zustand auftritt, und wenn diese Zeit kleiner oder gleich einem kalibrierten Zeitintervall X ist, dann kann der Bus-Off Zustand als ein Resultat von Fehlern angenommen werden, die durch einen fehlerhaften Controller verursacht sind, und wenn die Zeit größer als das Zeitintervall X ist, dann kann angenommen werden, dass der Bus-Off Zustand 26 ein Resultat der Fehler ist, die durch äußere Störungen verursacht sind. Wenn die Zeit kleiner als das Zeitintervall X ist, dann kann die Anwendungsschicht 18 ein kalibrierbares Resetwartezeit-Intervall Y vor einem Zurücksetzen des CAN-Controllers 16 einstellen, um dem CAN-Controller 16 zu ermöglichen, sich von dem Fehler zu erholen. Wenn die Zeit größer als das Zeitintervall X ist, dann kann die Anwendungsschicht 18 unmittelbar den CAN-Controller 16 zurücksetzen. Beide Zeitintervalle X und Y sind für langsame und schnellen CAN-Controller kalibrierbar, zum Beispiel kann das Zeitintervall für einen schnellen CAN-Controller X 1 Sekunde sein und für einen langsamen CAN-Controller 10 Sekunden, und das Zeitintervall Y kann für einen schnellen CAN-Controller 100 ms und für einen langsamen CAN-Controller 1 Sekunde sein.
3 ist ein Zeitdiagramm 30, das eine erste Lösung einer Bus-Off Resetstrategie für einen CAN-Controller zeigt, die nicht einen fehlerpassiven Zustand an die Anwendungsschicht 18 berichtet. Wenn der erste Bus-Off Zustand 26 zu dem Zeitpunkt 32 auftritt, wird der CAN-Controller 16 unmittelbar zurückgesetzt, und ein Timer wird gestartet. Falls der Timer eine Zeitspanne T₁ bis zum Zeitpunkt 34 bereitstellt, bei dem der nächste Bus-Off Zustand 26 auftritt, bestimmt die Anwendungsschicht 18, ob die Zeitspanne T₁ größer als oder kleiner als das Zeitintervall X ist. Wenn die Zeitspanne T₁ größer als das Zeitintervall X ist, bedeutet dies, dass der Bus-Off Zustand 26 wegen einer zufälligen Störung auftritt, und dann setzt die Anwendungsschicht 18 unmittelbar beziehungsweise sofort den CAN-Controller 16 zurück, und wenn die Zeitspanne T₁ kleiner als oder gleich dem Zeitintervall X ist, bedeutet dieses, dass der Bus-Off Zustand 26 auf Grund eines fehlerhaften Controllers auftritt, und dann wartet die Anwendungsschicht 18 das Zeitintervall Y ab, bevor sie den CAN-Controller 16 zurücksetzt, um dem Controller 16 Zeit zu geben, sich von dem Fehler zu erholen. Der gleiche Prozess wird für die Zeitspannen T₂ und T₃ durchgeführt, die mit dem Bus-Off Resetzeitpunkt 36 und dem nächsten Bus-Off Zustand 38 und dem Bus-Off Resetzeitpunkt 40 und dem nächsten Bus-Off Zustand 42 jeweils assoziiert sind.
Die oben beschriebene Bus-Off Resetstrategie hat den Nachteil, da der erste Bus-Off Zustand zum Zeitpunkt 32 immer als ein sofortiges Zurücksetzen behandelt wird, und selbst wenn es ein fehlerhafter Controller ist, kann der fehlerhafte Controller immer noch für die Zeitspanne T₁, zum Beispiel für 1 Sekunde, betrieben werden, bevor der nächste Bus-Off Zustand auftritt, wenn die Zeitspanne T₁, zum Bestimmen, ob der Bus-Off Zustand durch einen fehlerhaften Controller oder durch eine äußere Störung verursacht wird, verwendet werden kann, was auf dem Zeitintervall X basiert, in welchem Fall die Zeitspanne T₁ kleiner oder gleich dem Zeitintervall X sein würde, da der Bus-Off Zustand durch den fehlerhaften Controller verursacht wird und nur nach dem zweiten Bus-Off Zustand bei dem Zeitpunkt 34 eine Wartezeit zu seiner Rücksetzung bereitgestellt wird. Als ein Resultat wird die Störung von der fehlerhaften ECU für die Zeitspanne T₁, bis zu dem nächsten Bus-Off Zustand 26 bei dem Zeitpunkt 34 fortgesetzt. Somit erscheint die Bus-Unterbrechung um zusätzlich 1 Sekunde später als erwünscht.
Dieser Nachteil kann durch Zählen der Zeit zwischen dem Erreichen des fehlerpassiven Zustands 24 und dem Erreichen des Bus-Off Zustands 26 angesprochen werden, was typischerweise schnell ist. Diese sekundenschnelle Lösung der Bus-Off Resetstrategie wird durch das Zeitdiagramm 50 in 4 dargestellt, wobei ein Zeitgeber gestartet wird, wenn der CAN-Controller 16 in den ersten fehlerpassiven Zustand 24 eintritt, bevor der erste Bus-Off Zustand 26 auftritt. Von der Zeitspanne T₀, wenn der erste passive Zustand 24 bei dem Zeitpunkt 52 eintritt und der erste Bus-Off Zustand 26 bei dem Zeitpunkt 54 auftritt wird mit dem Zeitintervall X verglichen wird, um zu bestimmen, ob der Bus-Off Zustand 26 durch einen fehlerhaften Controller oder durch eine äußere Störung verursacht ist. Wenn der Bus-Off Zustand 26 durch einen fehlerhaften Controller verursacht ist, dann wird die Zeitspanne T₀ kleiner oder gleich zu dem Zeitintervall X sein, und die Anwendungsschicht 18 behandelt den Bus-Off Zustand 26 als einen internen Fehler und setzt den CAN-Controller 16 nach der Verzögerung des Zeitintervalls Y zurück. Wenn der Bus-Off Zustand 26 durch eine äußere Störung verursacht wird, wird die Zeitspanne T₀ größer als das Zeitintervall X sein, und die Anwendungsschicht 18 wird den CAN-Controller 16 sofort zurücksetzen. Der gleiche Prozess wird für die Zeitspannen T₁, T₂ und T₃ für den passiven Zustandszeitpunkt 56 und den Bus-Off Zustandszeitpunkt 58, den passiven Zustandszeitpunkt 60 und den Bus-Off Zustandszeitpunkt 62, den fehlerpassiven Zustandszeitpunkt 64 und den Bus-Off Zustandszeitpunkt 66 entsprechend ausgeführt.
Wenn somit der CAN-Controller 16 den fehlerpassiven Zustand 24 an die Anwendungsschicht 18 berichtet, dann kann die ECU 12 die zweite Lösung für ihre Bus-Off Resetstrategie verwenden, und wenn der CAN-Controller 16 nicht den fehlerpassiven Zustand 24 an die Anwendungsschicht 18 berichtet, dann kann die ECU 12 die erste Lösung für ihre Bus-Off Resetstrategie verwenden.
Für die erste Lösung, bei der die Bus-Off Zustandsbestimmung auf der Zeit von der letzten Bus-Off Resetzeit basiert, ist die Ausführung etwas reduziert, weil die Anwendungsschicht 18 nicht in der Lage ist, den ersten Bus-Off Zustand für eine fehlerhafte ECU zu identifizieren. Es entsteht jedoch für den CAN Bus-Controller 16 kein zusätzlicher Aufwand, den fehlerpassiven Zustand 24 zu berichten. Für die zweite Lösung für die auf der Zeit von dem fehlerpassiven Zustand 24 basierende Bus-Off Zustandsdifferenzierung wird die Ausführung der Bus-Off Resetstrategie verbessert, weil von der korrekten Identifikation des ersten Bus-Off für eine fehlerhafte ECU es jedoch zusätzlichen Aufwand für den CAN-Controller 16 gibt, um den fehlerpassiven Zustand 24 zu berichten.
5 ist ein Flussdiagramm 80, das einen Prozess zum Implementieren der Bus-Off Resetstrategie der ersten Lösung zeigt, die oben in 3 dargestellt wird. Wenn der CAN-Controller 16 in den Bus-Off Zustand übergeht, benachrichtigt er die Anwendungsschicht 18 durch eine CAN Unterbrechungsroutine, welche eine Bus-Off Zustandsmarke setzt, die den Bus-Off Zustand 26 anzeigt. Der Algorithmus in der Anwendungsschicht 18 führt den CAN Bus-Off Handhabungsalgorithmus periodisch in einer Zeitperiode T_a durch, wie 10 bis 20 Millisekunden, welche kleiner als die Zeitintervalle X und Y ist, um die Bus-Off Zustandsmarke zu überwachen und die Bus-Off Resetstrategie für ein Zurücksetzen des CAN-Controllers 16 in einen fehleraktiven Zustand 22 auszuführen. In dieser Ausführungsform zählen die Timer für die Zeitintervalle X und Y von ihrem Wert aus nach Null abwärts, wenn sie gestartet werden und wenn der Bus-Off Zustand 26 eintritt. Anfänglich werden beide Timer für die Zeitintervalle X und Y auf Null gesetzt. Wenn der Algorithmus in den Prozess eingreift, sobald die Zeitperiode T_a vorüber ist, bestimmt der Algorithmus, ob der Timer für das Zeitintervall X auf Null gesetzt ist, und falls nicht, vermindert er den Timer für das Zeitintervall X durch die Zeitperiode T_a am Block 82 und bestimmt, ob der Timer für das Zeitintervall Y auf Null gesetzt ist, und falls nicht, wird der Timer für das Zeitintervall Y durch die Zeitperiode T_a bei Block 84 herabgesetzt. Wenn somit entweder einer oder beide der Timer für die Zeitintervalle X und Y am Laufen sind, wenn der Prozess beginnt, werden sie in der Zeitperiode T_a auf ihrem Weg nach Null abfallen.
An der Entscheidungsraute 86 bestimmt der Algorithmus, ob die Bus-Off Marke auf 1 gesetzt wurde, was bedeutet, dass ein Bus-Off Zustand aufgetreten ist, und wenn nicht, endet der Algorithmus bei dem Block 88, um auf die nächste Zeitperiode T_a zu warten. Wenn die Bus-Off Marke bei der Entscheidungsraute 86 auf 1 gesetzt wurde, bestimmt der Algorithmus, ob der Timer für das Zeitintervall X bei der Entscheidungsraute 90 gleich Null ist. Wenn das Zurücksetzen eines Bus-Off Zustands 26 auftritt, wird der Timer für das Zeitintervall X gesetzt und beginnt in Inkrementen von T_a von dem Zeitwert X auf Null herunterzuzählen, um zu bestimmen, ob der nächste Bus-Off Zustand 26 relativ zu der Zeit aufgetreten ist. Wenn der Timer für das Zeitintervall X nicht gleich Null ist, dann erscheint der Bus-Off Zustand 26, bevor das Ende des Zeitintervalls X erreicht ist, hier 1 Sekunde, was bedeutet, dass der Bus-Off Zustand 26 auf Grund eines fehlerhaften ECU auftritt. In dieser Situation wird der Timer für das Zeitintervall X auf Null gesetzt, und der Timer für das Zeitintervall Y wird bei dem Block 92 gesetzt auf ein Zeitintervall Y, um den Controller 16 zu veranlassen, nachdem das Zeitintervall Y vorüber ist, zurückgesetzt zu werden, und der Algorithmus endet bei dem Block 88.
Wenn der Timer für das Zeitintervall X gleich Null bei der Entscheidungsraute 90 ist, was bedeutet, dass der Bus-Off Zustand 26 nachdem der Timer für das Zeitintervall X vorüber ist erscheint und der Bus-Off Zustand 26 ein Resultat von zufälligen Störungen ist und der Timer für das Zeitintervall Y für eine Wartezeit des Zurücksetzens prozessiert wird, bestimmt der Algorithmus dann, ob der Timer für das Zeitintervall Y Null an der Entscheidungsraute 94 ist. Wenn der Timer für das Zeitintervall Y an der Entscheidungsraute 90 nicht Null ist, dann wird der Algorithmus noch warten, bis die Wartezeit für ein Zurücksetzen vorüber ist, und der Algorithmus endet bei dem Block 88. Wenn der Timer für das Zeitintervall Y an der Entscheidungsraute 94 gleich Null ist, bedeutet dies, dass das ECU 12 in dem Bus-Off Zustand für die gewünschte Zeitperiode gewesen ist, um sich von dem Fehler zu erholen, so dass der Algorithmus zu der Box 96 weitergeht, um das Zurücksetzen des CAN-Controllers 16 in den fehleraktiven Zustand 22 zu starten, die Bus-Off Marke auf Null zu setzen und den Timer für das Zeitintervall X auf sein Zeitintervall zurückzusetzen, und der Algorithmus endet bei dem Block 88.
6 ist ein Flussdiagramm 100, das den Betrieb für die Bus-Off Resetstrategie für die zweite Lösung, die oben mit Bezug auf die Seite 4 erörtert wurde, zeigt, wobei ähnliche Blöcke des Flussdiagramms 80 die gleiche Referenznummer aufweisen. Für die Bus-Off Resetstrategie setzt die Unterbrechungsroutine sowohl die Bus-Off Marke, wenn die ECU 12 in dem Bus-Off Zustand 26 ist, als auch eine passive Fehlerzustandsmarke, wenn der CAN-Controller 16 in einem fehlerpassiven Zustand 24 ist. In diesem Prozess bestimmt der Algorithmus, nach dem die Timer für die Zeitintervalle X und Y durch die Periode T_a vermindert wurden, ob der CAN-Controller 16 in einem fehlerpassiven Zustand 24 ist, durch Bestimmen, ob die passive Fehlerzustandsmarke bei der Entscheidungsraute 102 gesetzt wurde, bevor bestimmt wurde, ob die Bus-Off Marke auf 1 gesetzt wurde. Wenn der passive Fehlerzustand 24 noch nicht bei der Entscheidungsraute 102 eingetreten ist, dann fährt der Algorithmus direkt mit der Entscheidungsraute 86 fort, um zu bestimmen, ob die Bus-Off Zustandsmarke gesetzt ist. Wenn jedoch der passive Fehlerzustand 24 bei der Entscheidungsraute 102 eingetreten ist, dann setzt der Algorithmus den Timer für das Zeitintervall X auf seinen Wert, der hier 1 Sekunde ist bei dem Block 104, weil das Zurücksetzen auf der Zeit basiert, bei welcher der CAN-Controller 16 in den fehlerpassiven Zustand 24 eintritt. Der Algorithmus setzt bei dem Block 104 auch die passive Fehlermarke auf Null, bevor er weitergeht, um zu bestimmen, ob die Bus-Off Marke bei der Entscheidungsraute 86 gesetzt wurde. Der CAN-Controller wird zurückgesetzt, und bei dem Block 106 wird die Bus-Off Marke auf Null gesetzt, wo das Zeitintervall X nicht bei dem Block 106 gesetzt wird, wenn der CAN-Controller 16 zurückgesetzt ist, weil er bei dem Block 104 zurückgesetzt worden ist.
Wie es für den Fachmann in der Technik verständlich ist, können die verschiedenen und unterschiedlichen Schritte und Prozesse, die hierin erörtert werden, um die Erfindung zu beschreiben, sich auf Operationen beziehen, die durch einen Computer, einen Prozessor oder andere elektronische Rechengeräte durchgeführt werden, die unter Verwenden von elektrischen Phänomenen Daten manipulieren und/oder transformieren. Derartige Computer und elektronische Geräte können unterschiedliche flüchtige und nichtflüchtige Speicher verwenden, die ein nichttransitorisches computerlesbares Medium mit einem ausführbaren Programm, das darin gespeichert ist, verwenden, die verschiedene Codes oder ausführbare Instruktionen einschließen, die in der Lage sind, durch den Computer oder Prozessor durchgeführt zu werden, wobei der Speicher und/oder das computerlesbare Medium alle Formen und Arten von Speichern und anderen computerlesbaren Medien einschließen.
Die vorhergehende Diskussion offenbart und beschreibt nur beispielhafte Ausführungsformen der vorliegenden Erfindung. Ein Fachmann der Technik wird bereits von einer derartigen Diskussion und von den begleitenden Zeichnungen und Ansprüchen erkennen, dass verschiedene Änderungen, Modifikationen und Variationen darin ausgeführt werden können, ohne von dem Geist und dem Rahmen der Erfindung, wie sie in den folgenden Ansprüchen definiert ist, abzuweichen.

Claims

Ein Verfahren zum Bestimmen, wann ein Controller in Antwort auf einen Bus-Off, der als Resultat einer Akkumulation einer ersten vorbestimmten Anzahl von Fehlern auftritt, die in Nachrichten identifiziert werden, die über einen Controller-Area-Network (CAN)-Bus übertragen werden oder aus einem Controller-Area-Network (CAN)-Bus empfangen werden, zurückzusetzen ist, wobei der Bus-Off Zustand dazu führt, das der Controller von dem Can-Bus getrennt wird, wobei das Verfahren aufweist: Bestimmen, dass der Controller in einen ersten Bus-Off Zustand eingetreten ist; sofortiges Zurücksetzen des Controllers in Antwort auf das Bestimmen, dass der Controller in den ersten Bus-Off Zustand eingetreten ist; Setzen eines Reset-Timers in Antwort darauf, dass der Controller zurückgesetzt worden ist; Bestimmen, ob der Controller in einen nachfolgenden Bus-Off Zustand eingetreten ist, nachdem der Controller zurückgesetzt wurde; Bestimmen, ob eine Reset-Zeitspanne ab einer Zeit, zu der oder nach der der Controller zurückgesetzt wird, bis zu dem nachfolgenden Bus-Off Zustand größer ist als ein erstes vorbestimmtes Zeitinterfall; sofortiges Zurücksetzen des Controllers in Antwort auf den nachfolgenden Bus-Off Zustand, falls die Reset-Zeitspanne größer als das erste vorbestimmte Zeitintervall ist; und Zurücksetzen des Controllers in Antwort auf den nachfolgenden Bus-Off-Zustand, nachdem ein zweites vorbestimmtes Zeitintervall abgelaufen ist, falls die Reset-Zeitspanne kleiner als das erste vorbestimmte Zeitintervall ist.
Das Verfahren nach Anspruch 1, ferner aufweisend Setzen des Reset-Timers in Antwort darauf, dass der Controller zurückgesetzt worden ist, Bestimmen, ob der Controller in einen anderen nachfolgenden Bus-Off Zustand eingetreten ist, nachdem der Controller zurückgesetzt wurde, Bestimmen, ob die Reset-Zeitspanne von ab oder nach dem der Controller zurückgesetzt wird, bis zu dem nachfolgenden Bus-Off Zustand größer als das erste vorbestimmte Zeitintervall ist, sofortiges Zurücksetzen des Controllers in Antwort auf den nachfolgenden Bus-Off Zustand, falls die Reset-Zeitspanne größer als das erste vorbestimmte Zeitintervall ist, und Zurücksetzen des Controllers in Antwort auf den nachfolgenden Bus-Off Zustand, falls die Zeitspanne kleiner als das erste vorbestimmte Zeitintervall ist, nachdem das zweite Zeitintervall für alle anderen Bus-Off Zustände nach dem nachfolgenden Bus-Off Zustand abgelaufen ist.
Das Verfahren nach Anspruch 1, wobei das Bestimmen, ob eine Reset-Zeitspanne ab einer Zeit, zu der oder nach der der Controller zurückgesetzt wird, bis zu dem nachfolgenden Bus-Off Zustand größer als ein erstes vorbestimmten Zeitintervall ist, ein Bestimmen, ob eine Reset-Zeitspanne ab wann der Controller zurückgesetzt wird bis zu dem nachfolgenden Bus-Off Zustand größer als ein erstes vorbestimmtes Zeitintervall ist, aufweist.
Das Verfahren nach Anspruch 1, weiter aufweisend Bestimmen, dass der Controller in einen fehlerpassiven Zustand eingetreten ist, der als ein Resultat einer Akkumulation einer zweiten vorbestimmten Anzahl von Fehlern auftritt, die in Nachrichten identifiziert werden, die über den CAN-Bus übertragen werden oder von dem CAN-Bus empfangen werden, wobei die zweite vorbestimmte Anzahl von Fehlern kleiner als die erste vorbestimmte Anzahl von Fehlern ist, wobei das Bestimmen, ob eine Reset-Zeitspanne ab einer Zeit, zu der oder nach der der Controller zurückgesetzt wird, bis zu dem nachfolgenden Bus-Off Zustand größer als ein erstes vorbestimmtes Zeitintervall ist, ein Bestimmen, ob eine Reset-Zeitspanne ab wann der Controller in den fehlerpassiven Zustand eingetreten ist bis zu dem nachfolgenden Bus-Off Zustand größer als ein erstes vorbestimmtes Zeitintervall ist, aufweist.
Das Verfahren nach Anspruch 1, wobei das erste vorbestimmte Zeitintervall bestimmt ist um zwischen Fehlern, die durch einen fehlerhaften Controller verursacht werden, und Fehlern, die durch äußere elektromagnetische Störungen verursacht werden zu unterscheiden.
Das Verfahren nach Anspruch 5, wobei das erste vorbestimmte Zeitintervall für einen Controller, der eine Geschwindigkeit von ungefähr 500 Kb/s hat, ungefähr eine Sekunde beträgt, und für einen Controller, das eine Geschwindigkeit von ungefähr 33Kb/s hat, ungefähr 10 Sekunden beträgt.
Das Verfahren nach Anspruch 5, wobei das zweite vorbestimmte Zeitintervall für einen Controller, der eine Geschwindigkeit von ungefähr 500 Kb/s hat, ungefähr 100 Millisekunden beträgt, und für einen Controller, der eine Geschwindigkeit von ungefähr 33 Kb/s hat, ungefähr eine Sekunde beträgt.
Das Verfahren nach Anspruch 1, wobei der Controller ein elektronisches Steuergerät (ECU) in einem Fahrzeug ist.
Ein Verfahren zum Bestimmen wann ein elektronisches Steuergerät (ECU) in eienm Fahrzeug, das Teil eines Controller-Area-Networks (CAN) ist, in Antwort auf einen Bus-Off Zustand, der als Resultat einer Akkumulation einer ersten vorbestimmten Anzahl von Fehlern auftritt, die in Nachrichten identifiziert werden, die über einen CAN-Bus übertragen werden oder von einem CAN-Bus empfangen werden, zurückzusetzen ist, wobei der Bus-Off Zustand bewirkt, dass das ECU von dem CAN-Bus getrennt wird, das Verfahren aufweisend: Bestimmen, dass das ECU in einen ersten Bus-Off Zustand eingetreten ist; sofortiges Zurücksetzen des Controllers in Antwort auf ein Bestimmen, dass das ECU in den ersten Bus-Off Zustand eingetreten ist; Setzen eines Reset-Timers in Antwort darauf, dass das ECU zurückgesetzt worden ist; Bestimmen, ob das ECU in einen nachfolgenden Bus-Off Zustand eingetreten ist, nachdem das ECU zurückgesetzt worden ist; Bestimmen, ob eine Reset-Zeitspanne ab einer Zeit zu der das ECU zurückgesetzt ist bis zu dem nachfolgenden Bus-Off Zustand größer als ein vorbestimmtes Zeitinterfall ist, wobei das erste vorbestimmte Zeitintervall bestimmt ist um zwischen Fehlern, die durch ein fehlerhaftes ECU verursacht werden, und Fehlern, die durch äußere elektromagnetische Störungen der ECU verursacht werden, zu unterscheiden; sofortiges Zurücksetzen des ECU in Antwort auf den nachfolgenden Bus-Off Zustand, falls die Reset-Zeitspanne größer als das erste vorbestimmte Zeitintervall ist; und Zurücksetzen des ECU, nachdem ein zweites vorbestimmtes Zeitintervall in Antwort auf den nachfolgenden Bus-Off Zustand abgelaufen ist, falls die Reset-Zeitspanne kleiner als das erste vorbestimmte Zeitintervall ist.
Das Verfahren nach Anspruch 9, weiter aufweisend Setzen des Reset-Timers in Antwort darauf, dass das ECU zurückgesetzt worden ist, Bestimmen, ob das ECU in einen anderen nachfolgenden Bus-Off Zustand eingetreten ist, nachdem das ECU zurückgesetzt wurde, Bestimmen, ob die Reset-Zeitspanne ab wann das ECU zurückgesetzt wird bis zu dem nachfolgenden Bus-Off Zustand größer als das erste vorbestimmte Zeitintervall ist, sofortiges Zurücksetzen des ECU in Antwort auf den nachfolgenden Bus-Off Zustand, falls die Reset-Zeitspanne größer als das erste vorbestimmte Zeitintervall ist, und Zurücksetzen des ECU in Antwort auf den nachfolgenden Bus-Off Zustand, falls die Zeitspanne kleiner als das erste vorbestimmte Zeitintervall ist, nachdem das zweite Zeitintervall für alle anderen Bus-Off Zustände nach dem nachfolgenden Bus-Off Zustand abgelaufen ist.
Das Verfahren nach Anspruch 10, wobei das erste vorbestimmte Zeitintervall für einen Controller, der eine Geschwindigkeit von ungefähr 500 Kb/s hat, ungefähr eine Sekunde beträgt, und für einen Controller, der eine Geschwindigkeit von ungefähr 33Kb/s hat, ungefähr 10 Sekunden beträgt.
Das Verfahren nach Anspruch 10, wobei das zweite vorbestimmte Zeitintervall für einen Controller, der eine Geschwindigkeit von ungefähr 500 Kb/s hat, ungefähr 100 Millisekunden beträgt, und für einen Controller, der eine Geschwindigkeit von ungefähr 33 Kb/s hat, ungefähr eine Sekunde beträgt.
Ein Verfahren zum Bestimmen wann ein elektronisches Steuergerät (ECU) in einem Fahrzeug, das Teil eines Controller-Area-Networks (CAN) ist in Antwort auf einen Bus-Off Zustand, der als Resultat einer Akkumulation einer ersten vorbestimmten Anzahl von Fehlern auftritt, die in Nachrichten identifiziert werden, die über einen CAN-Bus übertragen werden oder von einem CAN-Bus empfangen werden, zurückzusetzen ist, wobei der Bus-Off Zustand bewirkt, dass das ECU von dem CAN-Bus getrennt wird, das Verfahren aufweisend: Bestimmen, dass das ECU in einen fehlerpassiven Zustand eingetreten ist, der als ein Resultat einer Akkumulation einer zweiten vorbestimmten Anzahl von Fehlern auftritt, die in Nachrichten identifiziert werden, die über den CAN-Bus übertragen werden oder von dem CAN-Bus empfangen werden, wobei die zweite vorbestimmte Anzahl von Fehlern kleiner als die erste vorbestimmte Anzahl von Fehlern ist; Bestimmen, dass das ECU in einen ersten Bus-Off Zustand eingetreten ist; sofortiges Zurücksetzen des Controllers in Antwort auf das Bestimmen, dass das ECU in den ersten Bus-Off Zustand eingetreten ist; Setzen eines Reset-Timers in Antwort darauf, dass das ECU in einemn nachfolgenden fehlerpassiven Zustand eingetreten ist, nachdem das ECU zurückgesetzt wird; Bestimmen, ob das ECU in einen nachfolgenden Bus-Off Zustand eingetreten ist, nachdem das ECU in den fehlerpassiven Zustand eingetreten ist; Bestimmen, ob eine Reset-Zeitspanne ab einer Zeit zu der das ECU in den fehlerpassiven Zustand eingetreten ist bis zu dem nachfolgenden Bus-Off Zustand größer als ein erstes vorbestimmtes Zeitinterfall ist, wobei das erste vorbestimmte Zeitintervall zum Unterscheiden zwischen Fehlern, die durch ein fehlerhaftes ECU verursacht werden, und Fehlern, die durch äußere elektromagnetische Störungen des ECU verursacht werden, bestimmt ist; sofortiges Zurücksetzen des ECU in Antwort auf den nachfolgenden Bus-Off Zustand, falls die Reset-Zeitspanne größer als das erste vorbestimmte Zeitintervall ist; und Zurücksetzen des ECU in Antwort auf den nachfolgenden Bus-Off Zustand, nachdem ein zweites vorbestimmtes Zeitintervall abgelaufen ist, falls die Reset-Zeitspanne kleiner als das erste vorbestimmte Zeitintervall ist.
Das Verfahren nach Anspruch 13, weiter aufweisend Setzen eines Reset-Timers in Antwort darauf, dass das ECU in einen nachfolgenden fehlerpassiven Zustand eintritt nachdem das ECU zurückgesetzt wurde, Bestimmen, ob das ECU in einen nachfolgenden Bus-Off Zustand eingetreten ist, nachdem das ECU in den fehlerpassiven Zustand eingetreten ist, Bestimmen, ob die Reset-Zeitspanne ab dem Zeitpunkt zu dem das ECU in den fehlerpassiven Zustand zurückgesetzt worden ist, bis zu dem nachfolgende Bus-Off Zustand größer als das erste vorbestimmte Zeitintervall ist, sofortiges Zurücksetzen des ECU in Antwort auf den nachfolgenden Bus-Off Zustand, falls die Reset-Zeitspanne größer als das erste vorbestimmte Zeitintervall ist, und Zurücksetzen des ECU in Antwort auf den nachfolgenden Bus-Off Zustand, falls die Zeitspanne kleiner als das erste vorbestimmte Zeitintervall ist, nachdem das zweite Zeitintervall für alle anderen Bus-Off Zustände nach dem nachfolgenden Bus-Off Zustand abgelauffen ist.
Das Verfahren nach Anspruch 13, wobei das erste vorbestimmte Zeitintervall für einen Controller, der eine Geschwindigkeit von ungefähr 500 Kb/s hat, ungefähr eine Sekunde beträgt, und für einen Controller, das eine Geschwindigkeit von ungefähr 33Kb/s hat, ungefähr 10 Sekunden beträgt.
Das Verfahren nach Anspruch 13, wobei das zweite vorbestimmte Zeitintervall für einen Controller, der eine Geschwindigkeit von ungefähr 500 Kb/s hat, ungefähr 100 Millisekunden beträgt, und für einen Controller, der eine Geschwindigkeit von ungefähr 33 Kb/s hat, ungefähr eine Sekunde beträgt.