-
Die
vorliegende Erfindung betrifft eine Überwachungseinheit, die einem
Bus-Controller eines Teilnehmers eines Kommunikationssystems lokal
zugeordnet ist, zur Überwachung
und Steuerung des Zugriffs auf einen Datenbus gemäß einem
bestimmten Protokoll. Der Bus-Controller
greift über
einen Bus-Treiber auf den Datenbus zu, und die Überwachungseinheit überwacht
und steuert die Zugriffsberechtigung des Bus-Treibers gemäß Protokollspezifikation.
-
Die
Erfindung betrifft auch einen Teilnehmer eines einen Datenbus umfassenden
Kommunikationssystems. Der Teilnehmer weist einen Bus-Controller
und einen Bus-Treiber auf, wobei der Bus-Controller über den
Bus-Treiber an den Datenbus angeschlossen ist. Der Teilnehmer weist
außerdem
eine dem Bus-Controller zugeordnete Überwachungseinheit zur Überwachung
und Steuerung der Zugriffsberechtigung des Bus-Treibers auf den
Datenbus gemäß einer
bestimmten Protokollspezifikation auf.
-
Schließlich betrifft
die vorliegende Erfindung auch eine zentrale Überwachungseinheit eines Kommunikationssystems
zur Überwachung
und Steuerung des Zugriffs mehrerer Teilnehmer des Kommunikationssystems
auf einen Datenbus des Kommunikationssystems. Jeder Teilnehmer weist
einen Bus-Controller und einen Bus-Treiber auf, wobei der Bus-Controller über den
Bus-Treiber an den Datenbus angeschlossen ist. Die Überwachungseinheit überwacht
und steuert die Zugriffsberechtigung des Bus-Treibers mehrerer Teilnehmer
des Kommunikationssystems auf den Datenbus gemäß einer bestimmten Protokollspezifikation.
-
Stand
der Technik
-
Die
Vernetzung von Steuergeräten,
Sensorik und Aktuatorik mit Hilfe eines Kommunikationssystems oder
Datenübertragungssystems
und einer Kommunikationsverbindung, beispielsweise in Form eines
Bus-Systems oder eines Datenbusses, hat in den letzten Jahren in
modernen Kraftfahrzeugen aber auch in anderen Bereichen, beispielsweise
im Maschinenbau, insbesondere im Werkzeugmaschinenbereich, und in
der Automatisierung drastisch zugenommen. Synergieeffekte durch
Verteilung von Funktionen auf mehrere Teilnehmer, beispielsweise Steuergeräte, des
Kommunikationssystems können dabei
erzielt werden. Man spricht hierbei von verteilten Systemen.
-
Die
Kommunikation zwischen verschiedenen Teilnehmern eines solchen Kommunikationssystems findet
mehr und mehr über
ein Bus-System statt. Der Kommunikationsverkehr auf dem Bus-System,
Zugriffs- und Empfangsmechanismen, sowie Fehlerbehandlung werden über ein
Protokoll geregelt. Bekannte Protokolle sind beispielsweise CAN
(Controller Area Network), TTCAN (Time Triggard CAN), TTP/C (Time
Triggered Protocol Class C) und das FlexRay-Protokoll, wobei derzeit die FlexRay-Protokollspezifikation
v2.1 zu Grunde liegt. Bei FlexRay handelt es sich um ein schnelles,
deterministisches und fehlertolerantes Bussystem, insbesondere für den Einsatz
in Kraftfahrzeugen. Das FlexRay-Protokoll arbeitet nach dem Prinzip
des Time Division Multiple Access (TDMA), wobei den Teilnehmern
bzw. den zu übertragenden
Botschaften feste Zeitschlitze zugewiesen werden, in denen sie einen
exklusiven Zugriff auf die Kommunikationsverbindung haben. Die Zeitschlitze
wiederholen sich dabei in einem festgelegten Zyklus, so dass der
Zeitpunkt, zu dem eine Botschaft über den Bus übertragen
wird, exakt vorausgesagt werden kann und der Buszugriff deterministisch
erfolgt.
-
Um
die Bandbreite für
die Übertragung
von Botschaften auf dem Bussystem optimal zu nutzen, unterteilt
FlexRay den Kommunikationszyklus in einen statischen und einen dynamischen
Teil bzw. in ein statisches und ein dynamisches Segment. Die festen
Zeitschlitze befinden sich dabei im statischen Teil am Anfang des
Buszyklusses. Im dynamischen Teil werden die Zeitschlitze dynamisch
vorgegeben. Darin wird der exklusive Buszugriff jeweils nur für eine kurze
Zeit, für
die Dauer mindestens eines sogenannten Minislots, ermöglicht.
Nur wenn innerhalb eines Minislots ein Buszugriff erfolgt, wird
der Zeitschlitz auf die für
den Zugriff benötigte
Zeit verlängert.
Damit wird Bandbreite also nur verbraucht, wenn sie auch tatsächlich benötigt wird.
FlexRay kommuniziert über
eine oder zwei physikalisch getrennte Leitungen mit einer Datenrate
von jeweils maximal 10 Mbit/sec. Selbstverständlich kann FlexRay auch mit
niedrigeren Datenraten betrieben werden. Die beiden Kanäle entsprechen
dabei der physikalischen Schicht, insbesondere des sogenannten OSI(Open
System Architecture)- Schichtenmodells. Diese
dienen hauptsächlich
der redundanten und damit fehlertoleranten Übertragung von Botschaften, können jedoch
auch unterschiedliche Botschaften übertragen, wodurch sich dann
die Datenrate verdoppeln könnte.
Es ist auch denkbar, dass sich das über die Verbindungsleitungen übertragene
Signal als ein Differenzsignal als Differenz der über die
beiden Leitungen übertragenen
Signale ergibt. Die physikalitsche Schicht ist derart ausgestaltet,
dass sie eine elektrische aber auch optische Übertragung des oder der Signale über die
Leitungen) oder eine Übertragung
auf anderem Wege, bspw. über
Funk, ermöglicht.
-
Um
synchrone Funktionen zu realisieren und die Bandbreite durch kleine
Abstände
zwischen zwei Botschaften zu optimieren, benötigen die Teilnehmer in dem
Kommunikationsnetzwerk eine gemeinsame Zeitbasis, die sogenannte
globale Zeit. Für
die Synchronisation von lokalen Uhren der Teilnehmer werden Synchronisationsnachrichten
im statischen Teil des Zyklus übertragen,
wobei mit Hilfe eines speziellen Algorithmus entsprechend der FlexRay-Spezifikation die
lokale Uhrzeit (lokale Zeitbasis) eines Teilnehmers so korrigiert
wird, dass alle lokalen Uhren zu einer globalen Uhr (globale Zeitbasis)
synchron laufen.
-
Für die verschiedenen
bekannten Kommunikationssysteme gibt es eine Reihe von Möglichkeiten,
Zugriffskonflikte zu vermeiden oder zu lösen. In CAN wird zum Beispiel
die sogenannte bitweise Arbitrierung verwendet. Diese ist sehr robust.
Durch Laufzeit-Phänomene
ist aber die maximale Übertragungsgeschwindigkeit
prinzipbedingt limitiert. Bei zeitgesteuerten Kommunikationssystemen
wird das Zugriffsproblem per Ansatz und Konfiguration gelöst, die
Konflikte werden schon offline vermieden. Voraussetzung ist allerdings
ein gemeinsames Verständnis
der Zeit, das netzwerkweit Gültigkeit
hat (bei FlexRay: globale Zeitbasis). Bei diesen Systemen gibt es
aber in der Regel keine Möglichkeit,
im Fehlerfall die Zugriffskonflikte zu behandeln, da der Zugriff
an sich nicht verhindert werden kann. Deshalb ist es in verschiedenen
Kommunikationssystemen, beispielsweise TTP/C oder FlexRay, bekannt,
einen sogenannten Bus-Guardian (BG; Buswächter) als zusätzliche Überwachungseinheit
einzuführen,
der den physikalischen Zugriff auf den Datenbus nur in den vorab
konfigurierten Zeitabschnitten erlaubt. Damit ist der Zugriffskonflikt
auch im Fehlerfall lösbar
bzw. vermeidbar.
-
Bei
TTCAN, einer Kombination aus CAN und zeitgesteuertem Buszugriff,
wird der Konflikt über
die bitweise Arbitrierung gelöst.
Dabei kann es jedoch vorkommen, dass nicht der (zeitlich) richtige
Nachrichteninhalt bereitgestellt wird. Der Einsatz eines Bus-Guardian
für Nachrichten
im statischen Fenster (sogenanntes Static Window) kann bei TTCAN
deshalb sinnvoll sein, zum Beispiel für sicherheitsrelevante Systeme
wie X-by-Wire-Systeme.
-
In
aktuellen Konzepten wird der lokale Bus-Guardian über den
Takt des Bus-Controllers versorgt und dessen Rundeninformation für die Überwachungsfunktion
verwendet. Bei der derzeit aktuellen FlexRay-Protokollspezifikation
v2.1 wird ein Konzept beschrieben, das bezüglich der zeitlichen Überwachung
des Kommunikationsprotokolls bzw. des Kommunikations-Controllers
eingeschränkt
ist. In dem vorgeschlagenen Konzept taktet ein Makrotick (MT) des
lokalen FlexRay-Kommunikations-Controllers seinen lokalen Bus-Guardian. Der Zeitschlitz
mit Sendeaktivität
wird durch den Kommunikations-Controller zusätzlich durch ein ARM-Signal
angezeigt. Das Timing (die zeitlichen Aktivitäten) des zu überwachenden
FlexRay-Kommunikations-Controllers wird lediglich durch einen RC-Oszillator
grob überwacht
(Abweichungen werden erst ab etwa 30% erkannt) bzw. durch einen
zusätzlichen
Quarz-Oszillator auch mit höherer
Auflösung überwacht.
-
Prinzipiell
bleibt aber das Problem bestehen, dass durch die Makrotick-Versorgung
und die ARM-Signale kleinere Uhrendrifts des lokalen Kommunikations-Controllers
an den Bus-Guardian übertragen
werden. Das bedeutet also, dass falls die Uhrenkorrektur (zur Synchronisation
der lokalen Zeitbasis auf die globale Zeitbasis) des FlexRay-Kommunikations-Controllers gemäß der Protokollspezifikation v2.1
fehlerbehaftet arbeitet oder die Einstellung von Stell-Register
zur Uhrenkorrektur fehlerhaft und die Fehler unentdeckt sind, der
lokale Kommunikations-Controller im Vergleich zum restlichen Kommunikationsnetzwerk
driftet. Die Zeitschlitze zum Senden von Nachrichten werden sich
mit der Zeit in die Zeitschlitze der anderen Teilnehmer im Netzwerk
verschieben, ohne dass der lokale Bus-Guardian diese Situation erfassen
und entsprechende Gegenmaßnahmen
einleiten kann. Dieser Problemfall tritt insbesondere bei FlexRay
und TTCAN auf.
-
Ein
anderer Problemfall betrifft die Offset-Korrektur der lokalen Zeiten
der Teilnehmer, so dass die lokalen Zeiten synchron zu der globalen
Zeit des Kommunikationssystems laufen. Eine Offset-Korrektur gibt
es beispielsweise bei TTCAN, TTP/C, und FlexRay, wobei bei FlexRay die
Offset-Korrekturphase während
der sogenannten Network-Idle-Time (NIT) des lokalen Kommunikations-Controllers
am Ende eines Kommunikationszyklus erfolgt. Die Korrektur des Offsets
am Ende einer Kommunikationsrunde bzw. einer Doppelrunde verkürzt bzw.
verlängert
die lokale Runde innerhalb vorgegebener spezifizierter Grenzen.
Die nächste
Kommunikationsrunde beginnt aufgrund der Korrektur um einige sogenannte
Mikroticks (μT)
früher
oder später. Der
lokale Bus-Guardian muss diese Offset-Korrektur zulassen. Die Timerüberwachung
muss dies akzeptieren. Allerdings besteht beim Bus-Guardian kein
Wissen bezüglich
der Auswirkungen der Offset-Korrektur auf die nächste Kommunikationsrunde. Auch
in diesem Fall kann es zum Überschneiden
der Sende-Zeitschlitze der verschiedenen Teilnehmer kommen. Die
Wahrscheinlichkeit einer Überschneidung
erhöht
sich mit zunehmender Rundenzahl.
-
Das
Bus-Guardian-Konzept gemäß der FlexRay-Protokollspezifikation
v2.1 beruht auf der Annahme, dass die beschriebenen Fehlerfälle aufgrund permanenter
Störungen
nur mit geringer Wahrscheinlichkeit auftreten bzw. diese Störungen oder Fehler
durch zusätzliche
Maßnahmen
im Teilnehmer-Host bzw. durch ergänzende Funktionalitäten erkannt
werden können.
-
In
beiden genannten Problemfällen
liegt eine permanente Störung
des Kommunikations-Controllers
vor. Spontane Fehler führen
dagegen nicht zu dieser Situation, da das Kommunikationsprotokoll selbst
geeignete Korrekturmaßnahmen
umfasst bzw. Fehlerbehandlungsmaßnahmen vorsieht, um spontane
Fehler zu erkennen, zu korrigieren und zu beheben.
-
Ausgehend
von dem beschriebenen Stand der Technik liegt der vorliegenden Erfindung
die Aufgabe zugrunde, bekannte Überwachungskonzepte derart
zu erweitern, dass auch permanente Störungen in der Kommunikation
erkannt und gegebenenfalls korrigiert oder behoben werden können.
-
Ausgehend
von der lokalen Überwachungseinheit
der eingangs genannten Art wird vorgeschlagen, dass die Überwachungseinheit:
- – über den
Bus-Treiber an den Datenbus angeschlossen ist,
- – eine
Dekodiereinheit zum Dekodieren von über den Datenbus und den Bustreiber
empfangenen Nachrichten aufweist,
- – einen
Oszillatoranschluss aufweist,
- – eine
Uhrensynchronisationseinheit zur Synchronisation einer lokalen Uhr
der Überwachungseinheit
aufweist,
- – eine
Bus-Zugriffssteuerungseinheit zum Herstellen eines zeitlichen Zusammenhangs
zwischen empfangenen Nachrichten und einer Kommunikationsrunde gemäß Protokollspezifikation aufweist,
- – gemäß Kommunikationsschedule
vorgesehene Sendeinformationen des lokalen Bus-Controllers hat, und
- – eine
Vergleichereinheit zur Ermittlung von Abweichungen zwischen den
vorgesehenen Sendeinformationen und dem tatsächlichen Buszugriff des Bus-Controllers
bzw. des Bus-Treibers auf Grundlage der synchronisierten lokalen
Uhr der Überwachungseinheit
aufweist.
-
Dadurch,
dass die lokale Überwachungseinheit über dem
Bus-Treiber an den Datenbus angeschlossen ist, können über den Datenbus übermittelte
Botschaften nicht nur von dem Bus-Controller (bei FlexRay: Kommunikations-Controller),
sondern auch von der Überwachungseinheit
empfangen werden. Durch die Dekodiereinheit können die empfangenen Nachrichten
von der Überwachungseinheit
gemäß der in
dem Kommunikationssystem eingesetzten Protokollspezifikation dekodiert
werden. Durch diese beiden Maßnahmen,
Empfangen und Dekodieren von Nachrichten, ist es der erfindungsgemäßen lokalen Überwachungseinheit
möglich, über den
Datenbus versandte Synchronisationsnachrichten (sogenannte Sync-Frames)
zu empfangen und zu verstehen. Über
den Oszillatoranschluss kann die Überwachungseinheit einen eigenen,
von dem lokalen Bus-Controller völlig
unabhängigen
Zeittakt erhalten. Bei der Uhrensynchronisationseinheit handelt
es sich um eine Logik, durch die es der lokalen Überwachungseinheit möglich ist,
eine global synchronisierte Zeitbasis gemäß der in dem Kommunikationssystem zum
Einsatz kommenden Protokollspezifikation aufzubauen. Dabei werden
die empfangenen, dekodierten und ausgewerteten Synchronisationsnachrichten erfasst
und einer internen Korrektur, bspw. einer Rate- und Offset-Korrektur,
der lokalen Überwachungseinheit
zugeführt.
Bei der Bus-Zugriffssteuerungseinheit handelt es sich um eine Logik,
die den zeitlichen Zusammenhang zwischen dem Empfang der Synchronisationsnachrichten
und den Kommunikationsrunden gemäß der verwendeten
Protokollspezifikation herstellen kann. Die Bus-Zugriffssteuerungseinheit
wird auch als Media-Access-Control (MAC) bezeichnet. Die Vergleichereinheit
(sogenannter Komparator) der lokalen Überwachungseinheit ermittelt Unterschiede
zwischen einem Taktsignal der lokalen Überwachungseinheit bzw. den
daraus hergeleiteten vorgesehenen Sendeinformationen des Bus-Controllers
und dem tatsächlichen
Buszugriff des Bus-Controllers. Werden solche Unterschiede festgestellt,
wird vorzugsweise ein sogenanntes Fail-Silent-Verhalten der lokalen Überwachungseinheit
ausgelöst
und damit das Senden des lokalen Bus-Controllers vermieden.
-
Die
erfindungsgemäße lokale Überwachungseinheit
kann auch als Buswächter
oder Bus-Guardian
(BG) bezeichnet werden. Eine wesentliche Funktionalität der erfindungsgemäßen Überwachungseinheit
ist die vollständige
zeitliche Unabhängigkeit
von dem lokalen Bus-Controller
bzw. der lokalen Zeitbasis des Bus-Controllers und die Generierung
einer eigenen, lokalen Zeitbasis, die zu der globalen Zeit synchronisiert
wird. Durch ein Überprüfen der
Konsistenz der lokalen Zeitbasis der Überwachungseinheit zu der lokalen
Zeitbasis des zugeordneten Bus-Controllers können Zugriffsfehler, insbesondere
aufgrund permanenter Störungen,
sicher und zuverlässig
erkannt werden, selbst bei zunehmender Rundenzahl. Die eingangs
beschriebenen Fehlerfälle,
insbesondere aufgrund permanenter Störungen, sind mit der vorliegenden
Erfindung abgesichert und ein Fail-Silent-Verhalten des gesamten Teilnehmers
kann erreicht werden.
-
Die
vorliegende Erfindung beseitigt die konzeptionellen Schwachstellen
der bekannten Bus-Guardian-Konzepte,
die bei bisher bekannten Kommunikationssystemen eingesetzt werden.
Dabei ist eine kostenoptimierte Realisierung des Bus-Guardian-Konzepts
möglich,
da nur die für
den Empfang, das Dekodieren und Auswerten der Synchronisationsnachrichten
notwendigen Logik-Komponenten und Funktionalitäten in der erfindungsgemäßen lokalen Überwachungseinheit
vorgesehen sind. Bei den eingesetzten Komponenten handelt es sich
durchweg um an sich bekannte und an anderer Stelle in Kommunikationssystemen
eingesetzte Komponenten, die nunmehr auf besonders vorteilhafte
Weise in die erfindungsgemäße Überwachungseinheit
integriert werden. Die in die lokale Überwachungseinheit zusätzlich integrierten
Komponenten können
also ohne Weiteres auch in anderen Bereichen des Kommunikationssystems,
bspw. im Bus-Controller, eingesetzt werden, so dass sich hohe Stückzahlen
der Komponenten ergeben, was zu einer Zuverlässigkeit bei der Fertigung
und niedrigen Stückpreisen
führt. Außerdem kann
das erfindungsgemäße Konzept problemlos
in einen sogenannten Überwachungsrechner
eines Kommunikationssystems integriert werden. Eine solche zentrale Überwachungseinheit ist
nicht einem einzelnen Teilnehmer des Kommunikationssystems zugeordnet,
sondern überwacht
und steuert vielmehr den Zugriff mehrerer Teilnehmer des Kommunikationssystems
auf den Datenbus. Das Konzept des Überwachungsrechners hat den
Vorteil, dass nicht für
jeden Teilnehmer ein separater Bus-Guardian notwendig ist, sondern dass
deren Funktionalitäten
in einen einzigen oder mehrere wenige Überwachungsrechner integriert
werden können.
-
Bevorzugte
Ausführungsbeispiele
der vorliegenden Erfindung können
den Unteransprüchen
entnommen werden. Die Anwendung der lokalen Überwachungseinheit gemäß Anspruch
6 eignet sich insbesondere für
ein FlexRay-Kommunikationssystem, bei dem der Kommunikations-Controller
dem lokalen Bus-Guardian über
ein ARM-Signal den Beginn eines Kommunikationszyklus mitteilt. Das
Ausführungsbeispiel
gemäß Anspruch
7 eignet sich für
andere als FleyRay-Kommunikationssysteme, beispielsweise für ein TTCAN-Kommunikationssystem, wo
die Sendeinformationen des lokalen Bus-Controllers vorab im Bus-Guardian
abgelegt werden können.
Die abgelegten Sendeinformationen können beispielsweise zum Generieren
eines ARM-Signals herangezogen werden. Über die Referenznachricht wird
eine Rundensynchronisation erreicht bzw. plausibilisiert.
-
Zeichnungen
-
Bevorzugte
Ausführungsbeispiele
der Erfindung und weitere Vorteile der Erfindung werden anliegend
anhand der Figuren näher
erläutert.
Es zeigen:
-
1a eine
vereinfachte Topologie eines erfindungsgemäßen Kommunikationssystems gemäß einer
ersten bevorzugten Ausführungsform;
-
1b eine
vereinfachte Topologie eines erfindungsgemäßen Kommunikationssystems gemäß einer
weiteren bevorzugten Ausführungsform;
-
2 einen
aus dem Stand der Technik bekannten Teilnehmer eines Kommunikationssystems mit
bekanntem Bus-Guardian-Konzept;
-
3 den
Verlauf eines Enable-Signals, mit dem ein Bus-Guardian die Zugriffsberechtigung
eines Bus-Controllers bei einem bekannten Teilnehmer gemäß 2 steuert;
-
4 einen
erfindungsgemäßen Teilnehmer mit
einem neuartigen Bus-Guardian-Konzept
gemäß einer
bevorzugten Ausführungsform;
-
5 den
Verlauf eines Teils der Kommunikation über einen Datenbus des Kommunikationssystems
gemäß 1a und 1b.
-
Beschreibung
der Ausführungsbeispiele
-
Die
vorliegende Erfindung wird nachfolgend beispielhaft anhand eines
FlexRay-Kommunikationssystems
erläutert.
Selbstverständlich
kann die vorliegende Erfindung jedoch auch auf andere Kommunikationssysteme
angewandt werden, bei denen bereits jetzt schon andere Bus-Guardian-Konzepte
zum Einsatz kommen, oder bei denen das erfindungsgemäße Bus-Guardian-Konzept
sinnvoll erscheint und/oder Vorteile bringen würde.
-
In 1a ist
eine vereinfachte Topologie eines an sich bekannten FlexRay-Kommunikationssystems
in seiner Gesamtheit mit dem Bezugszeichen 1 bezeichnet.
Das Kommunikationssystem 1 umfasst eine physikalische Schicht,
die in dem vorliegenden Fall als ein Datenbus 2 mit zwei
elektrisch leitfähigen Leitungen
ausgebildet ist. Selbstverständlich
kann die physikalische Schicht auch durch optische Lichtwellenleiter
oder mittels Funkstrecken realisiert werden. Ebenso ist es denkbar,
nicht zwei separate Übertragungskanäle, sondern
lediglich einen Kanal vorzusehen. An den Datenbus 2 sind
mehrere FlexRay-Teilnehmer 3 angeschlossen, die auch als
Steuergeräte
oder Hosts bezeichnet werden. Streng genommen umfasst der Host jedoch
noch einen Mikrocontroller, der in 1a mit
dem Bezugszeichen 4 bezeichnet ist. Somit bilden der Teilnehmer 3 und
der Mikrocontroller 4 gemeinsam den eigentlichen Host 5.
-
Die
Teilnehmer 3 des FlexRay-Kommunikationssystems umfassen
jeweils einen FlexRay-Kommunikations-Controller 6 (sog.
Communication Controller), der über
den Datenbus 2 zu übertragende
Informationen 7 von dem Mikrocontroller 4 empfängt und
gemäß der in
dem Kommunikationssystem 1 verwendeten Protokollspezifikation,
in dem dargestellten Beispiel gemäß der FlexRay-Protokollspezifikation
v2.1, in das richtige Datenformat zur Übertragung über den Datenbus 2 bringt.
Die Informationen 7 in dem richtigen Datenformat werden
an den FlexRay-Bus-Treiber 8 (sog. Bus Driver) des Teilnehmers 3 übertragen,
der sie in eine für
die Übertragung über den
Datenbus 2 erforderliche Form, ebenfalls gemäß der verwendeten
Protokoll-Spezifikation, bringt.
-
Um
beispielsweise in sicherheitsrelevanten Applikationen des Kommunikationssystems 1 ein blockieren
des Datenbusses 2 durch einen defekten, ständig sendenden
Teilnehmer 3 (sog. babbling idiot) zu verhindern, sind
in den Teilnehmern 3 Buswächter 9 (sog. Bus
Guardian) vorgesehen, welche die Zugriffsberechtigung des Kommunikations-Controllers 6 überwachen
und steuern. Die Bus-Treiber 8 können nur dann Informationen
oder Datenpakete an den Datenbus 2 anlegen, wenn sie von
dem zugehörigen
Bus-Guardian 9 ein entsprechendes Freigabe-Signal (sog.
Enable-Signal) 10 erhalten.
-
Das
FlexRay-Kommunikationssystem 1 aus 1a hat
eine besonders einfache Topologie. Selbstverständlich kann die Topologie des
Datenbusses 2 auch ringförmig oder sternförmig ausgebildet sein.
Ebenso ist es denkbar, zur Übertragung
der Datenpakete über
größere Strecken
Verstärkerelemente,
beispielsweise als Bestandteil eines Active-Star, in der Datenbus-Struktur 2 anzuordnen.
-
In 1b ist
eine andere Topologie eines an sich ebenfalls bekannten FlexRay-Kommunikationssystems 1 dargestellt.
Diese Topologie unterscheidet sich von der aus 1a bekannten
Topologie insbesondere dadurch, dass die Teilnehmer 3 des
Kommunikationssystems 1 nicht jeweils mit einem separaten Bus-Guardian
ausgestattet sind. Vielmehr ist bei der in 1b dargestellten
Ausführungsform
die Bus-Guardian-Funktionalität
aus den einzelnen Teilnehmern 3 zu einem einzigen Überwachungsrechner 11 zusammengefasst
werden. Auch der Überwachungsrechner 11 verfügt über einen
Kommunikations-Controller 6 und einen Bus-Treiber 8,
so dass der Überwachungsrechner 11 Informationen über den Datenbus 2 senden
und empfangen kann. Die erweiterten Bus-Guardian-Funktionalitäten (Extended
Bus Guardian, BGX) des Überwachungsrechners 11 sind mit
dem Bezugszeichen 12 bezeichnet. Der Überwachungsrechner 11 ist
vorzugsweise außer über den Datenbus 2 noch über eine
andere Kommunikationsverbindung (nicht dargestellt) mit den Teilnehmern 3 verbunden,
so dass der Überwachungsrechner 11 die
Teilnehmer 3 selbst dann noch ansteuern und gegebenenfalls
ihre Sendeaktivität
unterbrechen kann, falls einer der Teilnehmer 3 ständig sendet
und dadurch den Datenbus 2 für jegliche Datenübertragung durch
die übrigen
Teilnehmer 3 und den Überwachungsrechner 11 blockiert.
Der Überwachungsrechner 11 hat
für jeden
der Teilnehmer 3 Informationen bezüglich seiner Sendeaktivitäten, überwacht
die Sendeaktivitäten
der Teilnehmer 3 und steuert sie.
-
In 2 ist
ein aus dem Stand der Technik bekannter FlexRay-Teilnehmer 3 mit
einem bekannten Bus-Guardian-Konzept dargestellt. Das in der FlexRay-Protokollspezifikation
v2.1 beschriebene Konzept ist bezüglich der zeitlichen Überwachung des
Kommunikationsprotokolls bzw. des Kommunikations-Controllers 6 eingeschränkt. Bei
dem Teilnehmer 3 mit dem bekannten Überwachungs-Konzept leitet
der Bus-Guardian 9 seine Zeitbasis von dem korrigierten
Makrotick(MT)-Signal 13 ab, das er von dem Kommunikations-Controller 6 erhält. Der Zeitschlitz
mit Sendeaktivität
(Zeitschlitz #2 in 3) wird zusätzlich durch ein ARM-Signal 14 des
Kommunikations-Controllers 6 angezeigt. Das ARM-Signal 14 dient
zur Synchronisation des Beginns eines Kommunikationszyklus bzw.
der Sendeschlitze des Kommunikationszyklus. Die zeitlichen Abfolgen
(das sogenannte Timing) des zu überwachenden
FlexRay-Kommunikations-Controllers 6 wird lediglich durch
einen RC-Oszillator 15 grob überwacht
bzw. durch einen zusätzlichen
Quarz-Oszillator auch mit höherer
Auflösung überwacht.
Der RC-Oszillator 15 erlaubt lediglich eine grobe Überwachung
des Makrotick-Signals 13, so dass Abweichungen erst oberhalb
von 20 bis 30 % des Signals als solche erkannt werden.
-
Somit
ist die Zeitbasis des Bus-Guardian 9 nicht unabhängig von
der Zeitbasis des Kommunikations-Controllers 6, sondern
abhängig
von dem Makrotick-Signal 13. Durch die Überwachung dieses Signals 13 mittels
des RC-Oszillators 15 kann eine vollständige Unabhängigkeit von der Zeitbasis
des Kommunikations-Controllers 6 nicht erzielt werden.
Die über
den Datenbus 2 zu übertragenden
Daten, die der Kommunikations-Controller 6 an den Bus-Treiber 8 übermittelt,
sind in 2 mit dem Bezugszeichen 16 bezeichnet.
Die Daten 16 werden über
den Bus-Treiber 8 an den Datenbus 2 angelegt.
Die Tätigkeit
des Bus-Treibers 8 wird aber durch den Bus-Guardian 9 so
weit überwacht
und/oder gesteuert, dass der Bus-Treiber 8 die Daten 16 nur
dann an den Datenbus 2 anlegen kann, wenn der Bus-Guardian 9 die Zugriffsberechtigung
des Bus-Treibers 8 bestätigt,
indem er ein Enable-Signal 17 an den Bus-Treiber 8 anlegt.
-
Das
bekannte Überwachungs-Konzept
hat insbesondere in den Fällen
Schwächen,
in denen permanente Störungen
vorliegen, die aufgrund von Fehlern oder Ungenauigkeiten in dem
Kommunikations-Controller 6 zu einer schleichenden Verschiebung
der Sende-Zeitschlitze des Teilnehmers 3 in die anderen
Sende-Zeitschlitze der übrigen
Teilnehmer 3 des Kommunikationszyklus. Solche schleichenden Fehler
im Timing können
durch das bekannte Konzept nicht erkannt werden, obwohl sie dem
Kommunikations-Schedule des Kommunikationssystems 1 widersprechen.
So besteht beispielsweise ein Problem, dass durch die Makrotick-Versorgung 13 und die
ARM-Signale 14 minimale Uhrendrifts des lokalen Kommunikations-Controllers 6 an
den Bus-Guardian 9 übertragen
werden können.
Falls also die Uhrenkorrektur des FlexRay-Kommunikations-Controllers 6 gemäß der Protokollspezifikation
v2.1 fehlerbehaftet arbeitet oder die Einstellung von Stell-Registern
des Kommunikations-Controllers 6, die zur Uhrenkorrektur
herangezogen werden, fehlerbehaftet und unentdeckt sind, driftet
der lokale Kommunikations-Controller 6 und damit auch der
lokale Bus-Guardian 9 im Vergleich zum restlichen Kommunikationsnetzwerk 1.
Da der Kommunikations-Controller 6 und der Bus-Guardian 9 gemeinsam
driften, kann der Bus-Guardian 9 auch keine Abweichungen
der Sendeaktivität
des Kommunikations-Controllers 6 von dem Kommunikations-Schedule
erkennen. Die Sendeschlitze des Kommunikationszyklus für den Teilnehmer 3,
dessen Kommunikations-Controller 6 Fehler oder Ungenauigkeiten
in der lokalen Zeitbasis aufweist, werden sich mit der Zeit also
in die Sende-Zeitschlitze der anderen Teilnehmer 3 in dem
Kommunikationsnetzwerk 1 schieben, ohne dass der lokale Bus-Guardian 9 diese
Situation erfassen und entsprechende Reaktionen auslösen könnte.
-
Einen
anderen Problemfall stellt die sogenannte Offset-Korrekturphase
während
der sogenannten Network Idle Time (NIT) des lokalen Kommunikations-Controllers 6 am
Ende eines Kommunikationszyklus dar. Die Offset-Korrekturphase dient unter
anderem zur Synchronisation der lokalen Zeitbasis des Teilnehmers 3 auf
die globale Zeitbasis des Kommunikationssystems 1. Um eine
solche Korrektur vorzunehmen, darf in spezifizierten Grenzen korrigiert
werden. Die nachfolgende Kommunikations-Runde beginnt dann um einige
Mikroticks (μT) früher oder
später.
Der lokale Bus-Guardian 9 muss diese Korrektur zulassen.
Die Timer-Überwachung muss
dies akzeptieren. Es besteht jedoch kein Bus-Guardian-Wissen bezüglich der
Auswirkungen der Offset-Korrektur auf die nächste Kommunikations-Runde.
Auch in diesem Fall kann es zum Überschneiden
der Sende-Zeitschlitze kommen. Die Wahrscheinlichkeit einer solchen Überschneidung erhöht sich
mit zunehmender Rundenzahl.
-
In 3 ist
der Verlauf des Enable-Signals 17 des in 2 dargestellten
bekannten Teilnehmers 3 mit dem bekannten Überwachungskonzept
dargestellt. Der dargestellte Teilnehmer 3 darf lediglich
in dem Sendeschlitz #2 senden, so dass das Enable-Signal 17 für den dargestellten
Teilnehmer 3 während des
gesamten Sendeschlitzes #2 das Senden von Daten durch den Bus-Treiber 8 erlauben
muss. Zur Sicherheit wechselt das Enable-Signal 17 eine
kurze Zeit vor Beginn des Sendeschlitzes #2 von "Disable" auf "Enable" und erst einige Zeit nach dem Ende
des Sendeschlitzes #2 von "Enable" wieder auf "Disable".
-
In 4 ist
ein erfindungsgemäßer Teilnehmer 3 eines
Kommunikationssystems 1 dargestellt, in dem das neuartige Überwachungskonzept
realisiert ist. Insbesondere der Bus-Guardian 9 des erfindungsgemäßen Teilnehmers 3 ist
zur Realisierung der vorliegenden Erfindung in besonderer Weise
ausgestaltet. Daraus ergibt sich als ein wesentlicher Unterschied
zu den bekannten Teilnehmern 3, dass der Bus-Guardian 9 eine
eigene lokale, von der Zeitbasis des Kommunikations-Controllers 6 völlig unabhängige Zeitbasis
hat. Diese lokale Zeitbasis des Bus-Guardians 9 wird ebenso
wie die Zeitbasis der Kommunikations-Controller 6 aller
Teilnehmer 3 auf die globale Zeitbasis des Kommunikations-Systems 1 synchronisiert.
Anhand der lokalen, unabhängigen
Zeitbasis des erfindungsgemäßen lokalen
Bus-Guardians 9 findet dann eine Bewertung und Steuerung
der Zugriffsaktivitäten
des Bus-Treibers 8 auf den Datenbus 2 statt.
-
Der
Bus-Guardian 9 enthält
zur Realisierung des neuartigen Überwachungs-Konzepts
im Wesentlichen die nachfolgenden Komponenten:
- – Einen
Anschluss 18, der zum Anschluss des Bus-Guardian 9 an
den Datenbus 2 über
den Bus-Treiber 8 dient.
- – Eine
Dekodiereinheit 19 zum Dekodieren von über den Datenbus 2 und
den Bus-Treiber 8 empfangenen
Nachrichten.
- – Einen
Oszillatoranschluss 20, über den ein Quarzoszillator 21 angeschlossen
werden kann und dem Bus-Guardian 9 ein Taktsignal 22 übermitteln
kann.
- – Eine
Uhrensynchronisationseinheit 23 zur Synchronisation der
lokalen Uhr des Bus-Guardian 9 an
die globale Zeitbasis des Kommunikationssystems 1, die
dem Bus-Guardian 9 über
Synchronisations-Nachrichten, die über den Datenbus 2 übertragen
werden, mitgeteilt wird.
- – Eine
Bus-Zugriffssteuerungseinheit 24 zum Herstellen eines zeitlichen
Zusammenhangs zwischen empfangenen Nachrichten und einem Kommunikationszyklus
gemäß der FlexRay-Protokollspezifikation.
- – Informationen über gemäß Kommunikationsschedule
vorgesehene Sendezeitpunkte des lokalen Kommunikations-Controllers 6,
welche der Bus-Guardian 9 in dem Ausführungsbeispiel aus 4 über das
Arm-Signal 14 erhält.
- – Eine
Vergleichereinheit 25, die zur Ermittlung von Abweichungen
zwischen den vorgesehenen Sendeinformationen gemäß dem ARM-Signal 14 und
dem tatsächlichen
Buszugriff auf Grundlage der synchronisierten lokalen Zeitbais des
Bus-Guardians 9 dient.
-
Der
Anschluss 18 und die Dekodiereinheit 19 werden
benötigt,
um über
den Datenbus 2 übertragene
FlexRay-Datenrahmen, insbesondere die Synchronisationsnachrichten
(sog. Sync-Frames), über den
Bus-Treiber 8 empfangen zu können. Damit wird in der Uhrensynchronisationseinheit 23 mit
Hilfe des Taktsignals 22 des Oszillators 21 eine
eigene Zeitbasis nach den Regeln der FlexRay-Protokollspezifikation
v2.1 aufgebaut. Auf Grundlage dieser eigenen lokalen Zeitbasis wird
in der Bus-Zugriffssteuerungseinheit 24, die auch als Media
Access Control (MAC) bezeichnet wird, die Konsistenz zum lokalen
Kommunikations-Controller 6 überprüft. Der Komparator 25 stellt
die erweiterte Funktionalität
des Bus-Guardians 9 zur Überwachung der Zeitinformation
des lokalen Kommunikations-Controllers 6 aufgrund der unabhängigen lokalen
Zeitbasis des Bus-Guardians 9 dar. Damit sind die eingangs
beschriebenen Fehlerfälle,
insbesondere aufgrund permanenter Störungen der Zeitbasis des Kommunikations-Controllers 6,
abgesichert und ein Fail-Silent-Verhalten des gesamten Hosts 5 sichergestellt.
-
In 5 sind
mehrere Kommunikationszyklen auf dem Datenbus 2 beispielhaft
dargestellt. Jeder Kommunikationszyklus umfasst in dem dargestellten
Beispiel vier Sendeschlitze #1 bis #4. Der Teilnehmer 3 aus 4 darf
in dem Sendeschlitz #2 über
den Datenbus 2 senden. Das bedeutet also, dass das Enable-Signal
zumindest für
die Dauer des gesamten Sendeschlitzes #2 auf "Enable" liegen muss. In dem vorangegangenen
Zeitschlitz #1 und in dem nachfolgenden Zeitschlitz #3 werden Synchronisationsnachrichten
S über
den Datenbus 2 übermittelt,
die von den Teilnehmern 3 empfangen und zur Synchronisation
der lokalen Zeitbasen in den Kommunikations-Controllern 6 der
Teilnehmer 3 herangezogen werden. Bei dem erfindungsgemäßen Überwachungs-Konzept
werden die Synchronisationsnachrichten S zusätzlich auch zur Synchronisation der
Bus-Guardians 9 herangezogen. Dazu werden die Nachrichten
S von dem Bus-Treiber 8 eines Teilnehmers 3 empfangen
und über
eine Verbindungsleitung (Sync) 26 an den Anschluss 18 des
Bus-Guardians 9 gelegt. Dort werden sie in der oben beschriebenen
Weise decodiert und zur Synchronisation der von der Zeitbasis des
Kommunikations-Controllers 6 unabhängigen eigenen
lokalen Zeitbasis des Bus-Guardians 9 herangezogen.
-
Die
vorliegende Erfindung beseitigt die konzeptionellen Schwachstellen
von bekannten Bus-Guardian-Konzepten
in der FlexRay-Protokollspezifikation v2.1, sowie in anderen Protokollspezifikationen. Dabei
ist eine kostenoptimierte Realisierung möglich, da nur notwendige Logik
bzw. Funktionalität
den Bus-Guardian 9 erweitert. In dem erfindungsgemäßen Bus-Guardian 9 können viele
Komponenten (Hardware-Beschreibungen) aus existierenden Kommunikations-Controllern 6 oder
anderen Bauteilen eines Kommunikationssystems übernommen werden.
-
Das
oben anhand der 4 und 5 beschriebene
neuartige Überwachungskonzept
kann nicht nur in die lokalen Bus-Guardians 9 der Teilnehmer 3 des
Kommunikationssystems 1 integriert werden, sondern könnte auch
in einen Überwachungsrechner 11 zu
einer erweiterten Bus-Guardian-Funktionalität 12 (BGX)
zusammengefasst sein (vergleiche 1b). Damit
wäre das
erfindungsgemäße Bus-Guardian-Konzept
also nicht in jedem einzelnen Teilnehmer 3 des Kommunikationssystems 1 realisiert,
sondern lediglich in einem oder mehreren Überwachungsrechnern 11,
die jeweils die Zugriffsberechtigung der Bus-Treiber 8 mehrerer
Teilnehmer 3 des Kommunikationssystems 1 überwachen
und/oder steuern.