DE3928537A1 - Verfahren zur fehlererkennung und/oder fehlerlokalisation bei datenuebertragungen - Google Patents
Verfahren zur fehlererkennung und/oder fehlerlokalisation bei datenuebertragungenInfo
- Publication number
- DE3928537A1 DE3928537A1 DE19893928537 DE3928537A DE3928537A1 DE 3928537 A1 DE3928537 A1 DE 3928537A1 DE 19893928537 DE19893928537 DE 19893928537 DE 3928537 A DE3928537 A DE 3928537A DE 3928537 A1 DE3928537 A1 DE 3928537A1
- Authority
- DE
- Germany
- Prior art keywords
- bus
- status
- error
- time
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
- B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
- B60R16/03—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for supply of electrical power to vehicle subsystems or for
- B60R16/0315—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for supply of electrical power to vehicle subsystems or for using multiplexing techniques
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
- Debugging And Monitoring (AREA)
Description
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.
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.
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ß.
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).
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19893928537 DE3928537A1 (de) | 1989-08-29 | 1989-08-29 | Verfahren zur fehlererkennung und/oder fehlerlokalisation bei datenuebertragungen |
JP2225461A JPH0392039A (ja) | 1989-08-29 | 1990-08-29 | データ伝送の際の障害検出及び/又は障害位置検出方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19893928537 DE3928537A1 (de) | 1989-08-29 | 1989-08-29 | Verfahren zur fehlererkennung und/oder fehlerlokalisation bei datenuebertragungen |
Publications (1)
Publication Number | Publication Date |
---|---|
DE3928537A1 true DE3928537A1 (de) | 1991-03-07 |
Family
ID=6388112
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19893928537 Withdrawn DE3928537A1 (de) | 1989-08-29 | 1989-08-29 | Verfahren zur fehlererkennung und/oder fehlerlokalisation bei datenuebertragungen |
Country Status (2)
Country | Link |
---|---|
JP (1) | JPH0392039A (de) |
DE (1) | DE3928537A1 (de) |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1992017017A1 (de) * | 1991-03-16 | 1992-10-01 | Robert Bosch Gmbh | Senderendstufe |
WO1992017016A1 (de) * | 1991-03-16 | 1992-10-01 | Robert Bosch Gmbh | Empfangskomparator |
DE10111286A1 (de) * | 2001-03-09 | 2002-09-19 | Audi Ag | Steuerungssystem und Verfahren zur Steuerung von Kraftfahrzeugkomponenten |
DE10127054A1 (de) * | 2001-06-02 | 2002-12-19 | Bosch Gmbh Robert | Verfahren zur Überwachung einer Spannungsversorgung eines Steuergeräts in einem Kraftfahrzeug |
US6636100B1 (en) | 1999-06-29 | 2003-10-21 | Mitsubishi Denki Kabushiki Kaisha | Can controller and one-chip computer having a built-in can controller |
DE10238547A1 (de) * | 2002-08-22 | 2004-03-04 | Bayerische Motoren Werke Ag | Steuersystem und Verfahren zur Fehlerbehebung in elektronischen Einheiten oder Teilnetzen |
WO2004024524A1 (de) * | 2002-09-04 | 2004-03-25 | Luk Lamellen Und Kupplungsbau Beteiligungs Kg | Verfahren und vorrichtung zum überprüfen von bremssignalen bei einem fahrzeug |
DE19581217B4 (de) * | 1994-09-11 | 2005-06-02 | Mecel Ab | Anordnung und Verfahren für ein Steuersystem eines Verbrennungsmotors |
DE19826388B4 (de) * | 1998-06-12 | 2007-01-11 | Sgs-Thomson Microelectronics Gmbh | Fehlerverarbeitungsschaltung für eine Empfangsstelle eines Datenübertragungssystems |
WO2009156512A1 (de) * | 2008-06-27 | 2009-12-30 | Airbus Operations Gmbh | Verfahren zum erkennen eines fehlerhaften knotens |
WO2016012387A1 (de) * | 2014-07-22 | 2016-01-28 | Continental Automotive Gmbh | Vorrichtung und verfahren zur fehler- und angriffserkennung für ein kraftfahrzeug |
DE112012006879B4 (de) | 2012-09-05 | 2022-01-20 | GM Global Technology Operations LLC | Neuer Ansatz zum Handhaben eines Controller-Area-Network Bus-Off |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100569147B1 (ko) * | 2004-06-17 | 2006-04-07 | 현대자동차주식회사 | 캔 타임아웃 통신오류 진단방법 |
-
1989
- 1989-08-29 DE DE19893928537 patent/DE3928537A1/de not_active Withdrawn
-
1990
- 1990-08-29 JP JP2225461A patent/JPH0392039A/ja active Pending
Cited By (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1992017017A1 (de) * | 1991-03-16 | 1992-10-01 | Robert Bosch Gmbh | Senderendstufe |
WO1992017016A1 (de) * | 1991-03-16 | 1992-10-01 | Robert Bosch Gmbh | Empfangskomparator |
DE19581217B4 (de) * | 1994-09-11 | 2005-06-02 | Mecel Ab | Anordnung und Verfahren für ein Steuersystem eines Verbrennungsmotors |
DE19826388B4 (de) * | 1998-06-12 | 2007-01-11 | Sgs-Thomson Microelectronics Gmbh | Fehlerverarbeitungsschaltung für eine Empfangsstelle eines Datenübertragungssystems |
US6636100B1 (en) | 1999-06-29 | 2003-10-21 | Mitsubishi Denki Kabushiki Kaisha | Can controller and one-chip computer having a built-in can controller |
DE10111286B4 (de) * | 2001-03-09 | 2005-04-21 | Audi Ag | Steuerungssystem und Verfahren zur Steuerung von Kraftfahrzeugkomponenten |
DE10111286A1 (de) * | 2001-03-09 | 2002-09-19 | Audi Ag | Steuerungssystem und Verfahren zur Steuerung von Kraftfahrzeugkomponenten |
DE10127054B4 (de) * | 2001-06-02 | 2004-09-30 | Robert Bosch Gmbh | Verfahren zur Überwachung einer Spannungsversorgung eines Steuergeräts in einem Kraftfahrzeug |
DE10127054A1 (de) * | 2001-06-02 | 2002-12-19 | Bosch Gmbh Robert | Verfahren zur Überwachung einer Spannungsversorgung eines Steuergeräts in einem Kraftfahrzeug |
US6949932B2 (en) | 2001-06-02 | 2005-09-27 | Robert Bosch Gmbh | Method for monitoring a power supply of a control unit in a motor vehicle |
DE10238547A1 (de) * | 2002-08-22 | 2004-03-04 | Bayerische Motoren Werke Ag | Steuersystem und Verfahren zur Fehlerbehebung in elektronischen Einheiten oder Teilnetzen |
US7328092B2 (en) | 2002-09-04 | 2008-02-05 | Luk Lamellen Und Kupplungsbau Beteiligungs Kg | Method and device for monitoring brake signals in a vehicle |
WO2004024524A1 (de) * | 2002-09-04 | 2004-03-25 | Luk Lamellen Und Kupplungsbau Beteiligungs Kg | Verfahren und vorrichtung zum überprüfen von bremssignalen bei einem fahrzeug |
WO2009156512A1 (de) * | 2008-06-27 | 2009-12-30 | Airbus Operations Gmbh | Verfahren zum erkennen eines fehlerhaften knotens |
DE102008002738A1 (de) * | 2008-06-27 | 2010-01-07 | Airbus Deutschland Gmbh | Verfahren zum Erkennen eines fehlerhaften Knotens |
DE102008002738B4 (de) * | 2008-06-27 | 2010-03-11 | Airbus Deutschland Gmbh | Verfahren zum Erkennen eines fehlerhaften Knotens |
US9634859B2 (en) | 2008-06-27 | 2017-04-25 | Airbus Operations Gmbh | Method for detecting a defective node |
DE112012006879B4 (de) | 2012-09-05 | 2022-01-20 | GM Global Technology Operations LLC | Neuer Ansatz zum Handhaben eines Controller-Area-Network Bus-Off |
WO2016012387A1 (de) * | 2014-07-22 | 2016-01-28 | Continental Automotive Gmbh | Vorrichtung und verfahren zur fehler- und angriffserkennung für ein kraftfahrzeug |
Also Published As
Publication number | Publication date |
---|---|
JPH0392039A (ja) | 1991-04-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE69433882T2 (de) | Vorrichtung zur Übertragung von Daten | |
DE3546662C3 (de) | Verfahren zum Betreiben einer Datenverarbeitungsanlage | |
DE112010001370B4 (de) | Signalübertragungsvorrichtung für einen Aufzug | |
DE69232686T2 (de) | Multiplex-Übertragungssystem | |
DE3919962C2 (de) | ||
DE3238532C3 (de) | Datenübertragungseinrichtung | |
DE4129205A1 (de) | Verfahren zum aufbau von botschaften fuer den datenaustausch und/oder fuer die synchronisation von prozessen in datenverarbeitungsanlagen | |
DE3928537A1 (de) | Verfahren zur fehlererkennung und/oder fehlerlokalisation bei datenuebertragungen | |
DE10156417A1 (de) | Fehlererfassungsvorrichtung für ein Fahrzeugübertragungsnetzwerk | |
EP0570338B1 (de) | Verfahren und Einrichtung zur Zugriffsüberwachung und zum Zugriffsschutz in Kommunikationsnetzwerken | |
DE10145218A1 (de) | Verfahren und Vorrichtung zur Zeitbestimmung in einem Bussystem und Bussystem | |
DE69318267T2 (de) | Vorrichtung zur Verwaltung eines Terminals und Verfahren zur Erkennung eines defekten Terminals unter Verwendung der Vorrichtung | |
EP0509114B1 (de) | Verfahren zum Übertragen von Daten an mehrere Datenstationen | |
DE4210115A1 (de) | Multiplex-uebertragungsverfahren | |
DE4238488A1 (de) | ||
EP1384122B1 (de) | Verfahren zur ansteuerung einer komponente eines verteilten sicherheitsrelevanten systems | |
EP0458781B1 (de) | Verfahren zur überwachung eines computer-netzwerks | |
DE4005087C1 (en) | Connector unit for domestic power installation - has adaptor for specific function allowing data transmission via bus and data lines | |
WO2000018064A2 (de) | Netzwerk sowie koppelgerät zur verbindung zweier segmente in einem derartigen netzwerk | |
EP1116360B1 (de) | Netzwerk sowie koppelgerät zur verbindung zweier segmente in einem derartigen netzwerk | |
EP1497735B1 (de) | Verfahren und vorrichtung zur überprufung einer überwachungsfunktion eines bussystems und bussystem | |
DE3882537T2 (de) | Verfahren und Vorrichtung für eine sichere und diagnostizierbare, Signalverwaschungen vermeidende Übertragung. | |
DE102019125493A1 (de) | Slaveeinrichtung, Bussystem und Verfahren | |
EP1329057B1 (de) | Verfahren für den Zugriff aauf einen Datenbus zwischen kommunizierenden elektronischen einheiten | |
DE3441930A1 (de) | Datentransfersystem |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8120 | Willingness to grant licenses paragraph 23 | ||
8141 | Disposal/no request for examination |