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 Triggered CAN), TTP/C (Time
Triggerrd 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.
Dabei kommuniziert FlexRay ü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 ergibt. Die physikalische Schicht
ist derart ausgestaltet, dass sie eine elektrische aber auch optische Übertragung
des oder der Signale über
die Leitung(en) 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. Die globale Zeit ist eine systemweit gültige Zeitbasis,
auf welche die lokalen Zeiten der Teilnehmer (Knoten oder Steuergeräte) des
Kommunikationssystems synchronisiert werden. Die globale Zeit spielt
für die
Zeitsteuerung in der Kommunikation und in der Applikation (zeitgesteuerte
Betriebssysteme wie beispielsweise (OSEKtime), aber auch für Diagnosefunktionen
und Fehlererkennung bzw. Fehlerbehandlung eine wichtige Rolle. Das
bedeutet, dass jeder Kommunikations-Controller (Host oder Teilnehmer)
eines solchen Kommunikationssystems eine eigene Uhr (beispielsweise
einen Quarz-Oszillator) besitzt, die über den Mechanismus der globalen
Zeit sogar mit allen anderen Uhren im System synchronisiert ist
(sogenannte lokale Zeitbasis). 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 eines Teilnehmers so korrigiert wird, dass alle lokalen Uhren
zu einer globalen Uhr 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 Zeit). 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 sind für sicherheitsrelevante
oder gar sicherheitskritische Anwendungen im Fahrzeug, bspw. für X-by-Wire-Systeme, Mechanismen
zur Sicherstellung einer fehlerfreien Datenübertragung über das Kommunikationssystem
und zur Freigabe von Aktuatorik des Sensors, z.B. von Elektromotoren
oder Hydraulikpumpen, erforderlich. Bei verschiedenen Kommunikationssystemen,
beispielsweise TTP/C oder FlexRay, ist es 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, 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 bekannten Konzept taktet ein Makrotick (MT) des lokalen
FlexRay-Kommunikations-Controllers seines 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
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 des FlexRay-Kommunikations-Controllers
gemäß der Protokollspezifikation
v2.1 fehlerbehaftet arbeitet oder die Einstellung der Stell-Register zur
Uhrenkorrektur fehlerhaft und unentdeckt sind, der lokale Kommunikations-Controller
im Vergleich zum restlichen Kommunikationsnetzwerk driftet. Die Zeitschlitze
zum Senden von Nachrichten (Sendeschlitze, Sendeslots) 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-Konekturphase 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 kein Bus-Guardian-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.
In
beiden genannten Problemfällen
liegt eine permanente Störung
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, korrigieren und zu beheben.
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.
Aus
dem Stand der Technik sind des weiteren verschiedene Verfahren zur Überwachung
von Steuergeräten
(oder Prozessrechner) bekannt. Dies kann nach dem Stand der Technik
durch eine sogenannte Frage-Antwort-Kommunikation auf Basis eines
1½-Rechner-Konzepts
ausgeführt
werden. In der
DE
198 26 131 A1 ist dieses Überwachungskonzept für eine Radeinheit
eines Brake-by-Wire-Systems dargestellt. Dabei wird das eigentliche
Steuergerät, das
für die
Ansteuerung der Aktuatorik (z.B. hydraulische Radbremsen) verantwortlich
ist, von einer Überwachungskomponente überwacht
und im Fehlerfall abgeschaltet. Die Überwachung des Steuergeräts basiert
auf einer Frage-Antwort-Kommunikation, die einem festgelegten Protokoll
folgt. Die Freigabe der Aktuatorik erfolgt ausschließlich bei
erfolgreicher Frage-Antwort-Kommunikation,
d.h. die von der Überwachungskomponente
an das Steuergerät
gestellte Frage wird von dem Steuergerät zum einen innerhalb eines
vorgegebenen Zeitfensters und zum anderen richtig beantwortet und
umgekehrt eine von dem Steuergerät
gestellte Frage wird von der Überwachungskomponente
innerhalb eines vorgegebenen Zeitfensters richtig beantwortet. Falls
dem Steuergerät
und der Überwachungskomponente
Fragen gestellt werden, welche die gleiche richtige Antwort haben,
erfolgt die Freigabe der Aktuatorik ausschließlich bei Übereinstimmung der Antwort
des Steuergeräts
mit der Antwort der Überwachungskomponente
(1½-Rechner-Konzept).
Das Prinzip der Freigabe basiert dabei auf einer elektrischen Schaltung,
der sogenannten Freigabeschaltung (in dem aus der
DE 198 26 131 A1 bekannten
Ausführungsbeispiel
in Form einer UND-Verknüpfung),
die zwischen dem Steuergerät
(dem Prozessrechner) und der Überwachungseinheit
realisiert ist. Das bedeutet, dass beide Komponenten, d.h. das Steuergerät und die Überwachungskomponente,
für eine
normale Funktion der Aktuatorik eine logische "1" an
die Freigabeschaltung anlegen müssen.
Die Abschaltung der Akuatorik erfolgt, sobald ein Prozess in dem Steuergerät das Signal
zur Abschaltung gibt. Die Überwachungskomponente
wird nur dann das Signal zur Abschaltung geben, wenn die überwachte
Komponente, d.h. das Steuergerät
(der Prozessrechner), als fehlerhaft erkannt wurde.
Die
Frage-Antwort-Kommunikation ist ein gängiges Verfahren zur Überwachung
von Steuergeräten
in einem Kraftfahrzeug. Die unabhängige Überwachungseinheit (der sogenannte Überwachungsrechner)
besitzt eine Liste an Fragen, die dem eigentlichen Prozessrechner
(Steuergerät)
vorzugsweise periodisch gestellt werden. Diese Fragen müssen
- a) innerhalb einer vorgegebenen, spezifizierten Zeit
beantwortet werden und
- b) die Antwort muss in einer entsprechenden Antworttabelle des Überwachungsrechners
als Antwort auf die zuvor gestellte Frage eingetragen sein.
Die
Auswahl der Fragen aus der Liste kann nach einem Zufallsverfahren
oder rein zyklisch erfolgen. Ein wichtiger Bestandteil der Frage-Antwort-Kommunikation
sind die Timer (Zeitgeber) zum vorzugsweise periodischen Starten
der Frage-Antwort-Kommunikation und zum Festlegen des für die Antworten
erlaubten Zeitfensters. Das Zeitfenster beschreibt den Zeitraum
zwischen dem frühest
möglichen
und dem spätest
möglichen
Eintreffen der Antwort.
Ausgehend
von dem beschriebenen Stand der Technik liegt der vorliegenden Erfindung
die Aufgabe zugrunde, bekannte Bus-Guardian-Konzepte für Kommunikationssysteme
dahingehend zu erweitern, dass auch permanente Störungen in
den Teilnehmern bzw. in den Bus-Controllern der Teilnehmer erkannt
und gegebenenfalls korrigiert oder behoben werden können.
Zur
Lösung
dieser Aufgabe wird ausgehend von der lokalen Überwachungseinheit der eingangs genannten
Art vorgeschlagen, dass die Überwachungseinheit
Mittel zur Realisierung einer Frage-Antwort-Kommunikation mit dem
Bus-Controller aufweist, und den Zugriff des Bus-Controllers auf den Datenbus nur dann
freigibt, wenn die Frage-Antwort-Kommunikation ein ordnungsgemäßes Funktionieren
des Bus-Controllers ergibt.
Erfindungsgemäß wird also
das von der Überwachung
von Steuergeräten
an sich bekannte Überwachungs-Konzept
zur Durchführung
einer Frage-Antwort-Kommunikation auf den Bus-Controller und die Überwachungseinheit der Teilnehmer
eines Kommunikationssystems übertragen.
Bei einem FlexRay-Kommunikationssystem wird das Überwachungs-Konzept also auf
den FlexRay-Kommunikations-Controller und den FlexRay-Bus-Guardian übertragen.
Selbstverständlich
ist das vorgeschlagene Überwachungskonzept
nicht auf den Einsatz in FlexRay-Kommunikationssystemen beschränkt, sondern kann
in belieben Kommunikationssystemen eingesetzt werden, die über eine Überwachungseinheit (z.B.
einen Bus-Guardian) zur Überwachung
der Funktion eines Bus-Controllers verfügen. Die Überwachungseinheit muss mit
Hilfe des Frage-Antwort-Konzepts mögliche Fehler im Bus-Controller, insbesondere
aufgrund von permanenten Störungen in
dem Bus-Controller, entdecken, die zu den eingangs beschriebenen
Problemstellungen führen.
Vorzugsweise
berücksichtigt
die Frage-Antwort-Kommunikation zwischen dem Bus-Controller und
der Überwachungseinheit
die folgenden Fehlermöglichkeiten:
- a) Input-Set für die Uhrensynchronisation
prüfen
- b) korrekte Berechnung der Rate-Korrektur
- c) korrekte Anwendung der Rate-Korrektur
- d) korrekte Berechnung der Offset-Korrektur
- e) korrekte Anwendung der Offset-Korrektur
Die Überwachungseinheit übernimmt
dabei die Aufgabe eines Überwachungsrechners
und stellt, vorzugsweise periodisch, Fragen an den ihr zugeordneten
Bus-Controller, um dann den Eingang der richtigen Antwort innerhalb
eines spezifizierten Zeitfensters zu überwachen. Für den Fall,
dass das Zeitfenster nicht eingehalten wird eine eine falsche Antwort auf
die Frage eintrifft, übernimmt
die Überwachungseinheit
die Abschaltung des Bus-Controllers bzw. verhindert das aktive Senden
von Nachrichten durch den Bus-Controller. Die Reaktion der Überwachungseinheit
auf eine fehlgeschlagene Frage-Antwort-Kommunikation kann entweder
temporärer
Natur sein (für
einen oder mehrere Kommunikationszyklen), oder aber von dauerhafter
Natur sein (bis zum Herunterfahren des Teilnehmers oder des gesamten Kommunikationssystems).
Die
vorliegende Erfindung beseitigt die konzeptionellen Schwachstellen
des bisher bekannten Überwachungs-Konzepts,
insbesondere des bekannten Bus-Guardian-Konzepts in der FlexRay-Protokollspezifikation
v2.1. Dabei ist eine kostenoptimierte Realisierung möglich, da
nur notwendige Logik/Funktionalität die Überwachungseinheit erweitert, nämlich die Überwachungsfunktionalität der Frage-Antwort-Kommunikation.
Die Integration des Konzepts in sogenannte Überwachungsrechner hat besondere
Vorteile. Dadurch sind Kosteneinsparungen bei der Einführung neuer
Kommunikationssystem-Technologien, beispielsweise der FlexRay-Technologie, mit
der Forderung nach einer Überwachungseinheit
(Bus-Guardian) werden ermöglicht.
Es ist keine separate Überwachungseinheit
(Bus-Guardian) notwendig, sondern die vorliegende Erfindung kann
in das bestehende Überwachungsrechnerkonzept
integriert werden.
Die
vorliegende Erfindung hat besondere Vorteile für die Realisierung in einem
FlexRay-Kommunikationssystem,
wobei die Bus-Guardians und die Kommunikations-Controller der Teilnehmer
eines FlexRay-Kommunikationssystems zur Durchführung der Frage-Antwort-Kommunikation ausgebildet
sind. Zur Realisierung des Konzepts muss lediglich die Überwachungseinheit
um eine Liste von Fragen und entsprechenden Antworten ergänzt werden.
Die Überwachungseinheit
wird um einen Mechanismus ergänzt,
der das vorzugsweise periodische Fragen, das Setzen entsprechend
der Zeitgeber (Timer) für das
Zeitfenster, die Überwachung
dieses Zeitfensters und die Überprüfung der
Antwort ermöglicht.
Schließlich
hat die Überwachungseinheit
einen Pin zur Freigabe des Bus-Controllers und zum Bedienen einer eventuell
in dem Teilnehmer vorhandenen Freigabeschaltung. Bei dem vorgeschlagenen
Konzept wird gezielt die Logik des Bus-Controllers getestet, die
für die
Berechnung der Uhrensynchronisationswerte (für eine Synchronisation der
lokalen Zeitbasis des Teilnehmers auf die globale Zeitbasis des
Kommunikationssystems) zuständig
ist. Des Weiteren kann ein einfacher Read-Back-Mechanismus auf die
relevanten Stell-Register für
die Uhrensynchronisation durchgeführt werden. Hierzu ist eine
erweiterte Schnittstelle zwischen der Überwachungseinheit und dem
Bus-Controller vorgesehen. Das FlexRay-Protokoll beispielsweise
schlägt
derzeit den Austausch von Informationen über eine SPI (Serial Peripheral Interface)-Schnittstelle
vor. Bei der SPI-Schnittstelle handelt es sich um einen einfachen
synchronen, seriellen Datenbus. Diese Schnittstelle wäre auch
ausreichend für
die Frage-Antwort-Kommunikation
gemäß der vorliegenden
Erfindung. Die bisherige Funktionalität der Überwachungseinheit, beispielsweise die
Funktionalität
des Bus-Guardian gemäß FlexRay-Protokollspezifikation
v2.1, kann vollständig
erhalten bleiben.
Um
das Input-Set für
die Uhrensynchronisation des Teilnehmers zu prüfen, wird erfindungsgemäß vorgeschlagen,
dass die Überwachungseinheit um
eine Logik erweitert wird, die gezielt das Input-Set des Bus-Controllers
für die
Uhrensynchronisation überprüft. Ziel
ist es, die Qualität
der Uhrensynchronisation hoch zu halten und Fehler aufgrund von
permanenten Störungen
zu detektieren und ggf. zu unterbinden. Gelingt dies nicht, sollte
der Teilnehmer bzw. der Bus-Controller oder der Bus-Treiber in einen Fail-Silent-Mode
gesetzt werden, um das Senden des Bus-Controllers zu vermeiden bzw.
eine eventuell vorhandene Freigabeschaltung für den Bus-Controller zu sperren.
Hierzu wird die Überwachungseinheit über eine
Schnittstelle zum Bus-Controller mit Informationen bezüglich der
Synchronisationsnachrichten (Sync-Frames; Datenrahmen zur Synchronisation
der lokalen Zeitbasis) versorgt, welche die Grundlage für die Uhrensynchronisation
in dem Bus-Controller bilden. Der Überwachungseinheit werden also
Informationen zur Verfügung
gestellt, welche der Sync-Frames von dem lokalen Bus-Controller
empfangen, dekodiert und für
die Berechnung von Korrekturwerten (für die lokale Zeitbasis) herangezogen
wurden. Hierzu kann in dem Bus-Controller eine Liste mit Informationen
bezüglich
der Synchronisationsnachrichten angelegt werden, wie dies beispielsweise
in der FlexRay-Protokollspezifikation v2.1 vorgeschlagen ist. Diese
Liste kann nun im Rahmen der Frage-Antwort-Kommunikation folgenden Prüfungen unterzogen
werden:
- a) Es kann eine Mehrheitsentscheidung über die Anzahl
der vorliegenden Sync-Frames ausgeführt werden. Falls eine kritische
Anzahl an Sync-Frames unterschritten wird, besteht die Gefahr, dass die
nachfolgenden Berechnungen der Korrekturwerte auf Grundlage einer
ungenauen lokalen Zeitbasis erfolgten und damit zu falschen Ergebnissen
führen.
Die Grenze der minimal zulässigen Anzahl
an Sync-Frames ist vorzugsweise an die Einstellungen des Bus-Controllers
angepasst. Eine entsprechende Überprüfung der
Anzahl der vorliegenden Sync-Frames kann auch in dem Bus-Controller ausgeführt werden.
Durch die redundante Ausführung
der Überprüfung der
Anzahl der vorliegenden Sync-Frames durch die Überwachungseinheit kann eine
Konsistenzprüfung
ausgeführt
werden. Falls unterschiedliche Ergebnisse vorliegen, sollte die Überwachungseinheit
des Senden von Nachrichten durch den lokalen Bus-Controller vermeiden bzw. eine eventuell
vorhandene Freigabeschaltung sperren.
- b) Falls Informationen in dem Kommunikationssystem über zwei
separate Kanäle
redundant übertragen
werden, kann auch die Anzahl und die Identifikation der Synchronisationsnachrichten (Sync-Frames)
beider Kanäle
verglichen werden. Diese Informationen stehen ebenfalls in dem Bus-Controller
zur Verfügung
(vergleiche beispielsweise FlexRay-Protokollspezifikation v2.1). Falls
unterschiedliche Ergebnisse vorliegen, muss die Überwachungseinheit das Senden
von Nachrichten durch den lokalen Bus-Controller vermeiden bzw.
eine eventuell vorhandene Freigabeschaltung sperren.
Eine
durch einen Bus-Controller berechnete, fehlerhafte Rate-Korrektur
für die
globale Zeitbasis des Kommunikationssystems, welche dann die lokale
Zeitbasis des Teilnehmers bzw. Bus-Controllers ergibt, kann verschiedene
Ursachen haben. Die fehlerhafte Berechnung kann sich aufgrund eines
inkorrekten Input-Sets oder aufgrund eines Fehlers in einer Berechnungs-Logik des Bus-Controllers
ergeben. Zum Überprüfen eines
ordnungsgemäßen Funktionierens
der Berechnungs-Logik werden verschiedene Möglichkeiten vorgeschlagen:
- a) In der Überwachungseinheit
wird die Berechnung der Rate-Korrektur in gleicher Weise vollzogen
wie in dem Bus-Controller, d.h. in der Überwachungseinheit gibt es
eine identische Umsetzung des Mechanismus des Bus-Controllers zur Berechnung
der Rate-Korrektur.
Die Werte des Input-Sets liegen in der oben beschriebenen Weise in
der Überwachungseinheit
vor. Die Berechnungsergebnisse liegen auch in dem Bus-Controller vor und
können
mit den Ergebnissen der Überwachungseinheit
abgeglichen werden. Hierzu ist zusätzliche Kommunikation über eine
Schnittstelle zwischen der Überwachungseinheit
und dem Bus-Controller notwendig. Falls unterschiedliche Ergebnisse
vorliegen, muss die Überwachungseinheit
das Senden von Nachrichten durch den lokalen Bus-Controller vermeiden
bzw. eine eventuell vorhandene Freigabeschaltung sperren.
- b) Die Überwachungseinheit
kann auch gezielte Fragen an die Berechnungs-Logik des Bus-Controllers
stellen, die für
die Berechnung der Rate-Korrektur-Werte zuständig ist. Die Berechnungslogik
muss eine Antwort an die Überwachungseinheit
zurückliefern.
Die geforderte Antwort hat innerhalb eines festgelegten Zeitfensters zu
erfolgen. Die Überwachungseinheit
vergleicht das Ergebnis mit der entsprechenden lokal abgespeicherten
Antwort auf die Frage. Damit wird die korrekte Funktion der Berechnungs-Logik
für die Rate-Korrektur
des Bus-Controllers vorzugsweise periodisch überprüft. Permanente Störungen und die
daraus resultierenden Fehler können
so festgestellt werden. In diesem Fall muss die Überwachungseinheit das Senden
von Nachrichten durch den lokalen Bus-Controller vermeiden bzw.
eine Freigabeschaltung entsprechend sperren.
Die
Ursache für
eine falsche Anwendung eines korrekt berechneten Wertes für die Rate-Korrektur für die globale
Zeitbasis durch den Bus-Controller kann verschiedene Ursachen haben.
Zum Einen kann es an Fehlern in der Logik zur Makrotick (MT)-Generierung
und zum Anderen in Fehlern eines Speicherelements, beispielsweise
eines Speicherregisters, für
den Korrekturwert liegen, so dass ein falscher Korrekturwert in
der Makrotick-Generierung verwendet wird. Erfindungsgemäß werden
folgende Mechanismen vorgeschlagen:
- a) Die Überwachungseinheit
erhält
einen Wert für die
Rate-Korrektur von dem Bus-Controller über die
Schnittstelle mitgeteilt und vergleicht den Wert mit dem entsprechenden
Speicherwert in einem Stellregister des Bus-Controllers. Falls unterschiedliche
Ergebnisse vorliegen, muss die Überwachungseinheit
das Senden von Nachrichten durch den lokalen Bus-Controller vermeiden
bzw. die Freigabeschaltung sperren.
- b) Die Überwachungseinheit
kann gezielte Fragen an die Logik des Bus-Controllers stellen, die
für die
Makrotick-Generierung zuständig
ist. Die Logik muss eine Antwort an die Überwachungseinheit zurückliefern.
Die geforderte Antwort muss innerhalb eines festgelegten Zeitfensters
erfolgen. Die Überwachungseinheit
vergleicht das Ergebnis mit einer entsprechenden lokal abgespeicherten Antwort
auf diese Frage. Damit wird die korrekte Funktion der Makrotick-Generierungs-Logik
vorzugsweise periodisch überprüft. Permanente
Störungen
und die daraus resultierenden Fehler können festgestellt werden. In
diesem Fall muss die Überwachungseinheit
das Senden von Nachrichten durch den lokalen Bus-Controller vermeiden bzw.
eine eventuell vorhandene Freigabeschaltung sperren.
- c) Die Überwachungseinheit
erhält
am Ende einer Kommunikationsrunde von dem Bus-Controller die Anzahl der Mikroticks
(μT) pro
Runde bzw. die Anzahl der Mikroticks (μT) pro Makrotick (MT) mitgeteilt.
Die Information wird über
die Schnittstelle zwischen dem Bus-Controller und der Überwachungseinheit
ausgetauscht. Die Informationen werden von Runde zu Runde ausgetauscht
und abgeglichen. Für
den Vergleich durch die Überwachungseinheit
sind Grenzen festzulegen, d.h. ein zulässiger Drift in Mikrotick pro
Runde bzw. Mikrotick pro Makrotick spezifiziert. Überschreitet bzw.
unterschreitet der Vergleich eine festgesetzte Ober- bzw. Untergrenze,
kann die Überwachungseinheit
das Senden von Nachrichten durch den lokalen Bus-Controller vermeiden
bzw. eine eventuell vorhandene Freigabeschaltung sperren.
Der
Bus-Controller kann aufgrund eine fehlerhaften Input-Sets oder aufgrund
eines Fehlers in der Berechnungs-Logik des Bus-Controllers eine
fehlerhafte Offset-Korrektur für
die globale Zeitbasis des Kommunikationssystems, auf welche die
lokale Zeitbasis des Teilnehmers synchronisiert wird. Zur Detektion
eines fehlerhaften Input-Sets wurden bereits oben mehrere Vorschläge gemacht.
Zur Detektion eines Fehlers in der Berechnungs-Logik für die Offset-Korrektur werden
folgende Mechanismen vorgeschlagen:
- a) In der Überwachungseinheit
wird die Offset-Korrektur aus dem Bus-Controller nachvollzogen.
Beispielsweise ist in der Überwachungseinheit
eine 1:1-Umsetzung des Mechanismus aus dem Bus-Controller ausgebildet.
Die Werte des Input-Sets liegen – wie bereits oben beschrieben – in der Überwachungseinheit
vor. Die Berechnungsergebnisse der Offset-Korrektur liegen auch in
dem Bus-Controller vor und können
mit dem Ergebnissen der Überwachungseinheit
verglichen werden. Hierzu ist zusätzliche Kommunikation über die
Schnittstelle zwischen der Überwachungseinheit
und dem Bus-Controller notwendig. Falls unterschiedliche Ergebnisse
vorliegen, muss die Überwachungseinheit
das Senden von Nachrichten durch den lokalen Bus-Controller vermeiden bzw. eine eventuell
vorhandene Freigabeschaltung sperren.
- b) Die Überwachungseinheit
stellt gezielte Fragen an die Logik des Bus-Controllers, die für die Berechnung
der Offset-Korrektur-Werte zuständig ist.
Die Berechnungslogik muss eine Antwort an die Überwachungseinheit zurückliefern.
Die geforderte Antwort hat innerhalb festgelegter Zeitfenster zu
erfolgen. Die Überwachungseinheit vergleicht
das Ergebnis mit ihren lokal abgespeicherten Antworten. Insbesondere
wird überprüft, ob die
Antwort des Bus-Controllers die richtige Antwort auf die gestellte
Frage ist. Damit wird die korrekte Funktion der Berechnungs-Logik
vorzugsweise periodisch überprüft. Permanente
Störungen
und die daraus resultierenden Fehler werden detektiert. In diesem
Fall muss die Überwachungseinheit
das Senden von Nachrichten durch den lokalen Bus-Controller vermeiden
bzw. eine eventuell vorhandene Freigabeschaltung sperren.
Die
Ursache, dass der Bus-Controller eine korrekt errechnete Offset-Korrektur
für die
globale Zeitbasis nicht richtig anwendet, kann in der Logik der
Offset-Anwendung oder in einem Speicherelement, beispielsweise einem
Speicherregister, für
den Korrekturwert liegen. Dies führt
auf jeden Fall dazu, dass ein falscher Korrekturwert für die Offset-Korrektur
verwendet wird.
Zur Überprüfung der
korrekten Anwendung der Offset-Korrektur werden verschiedene Mechanismen
vorgeschlagen:
- a) Die Überwachungseinheit erhält den Offset-Korrekturwert
von dem Bus-Controller über die
Schnittstelle mitgeteilt und vergleicht den Korrekturwert mit dem
Speicherwert in einem Stellregister des Bus-Controllers. Falls unterschiedliche Ergebnisse
vorliegen, muss die Überwachungseinheit
das Senden von Nachrichten durch den lokalen Bus-Controller vermeiden bzw. eine eventuell
vorhandene Freigabeschaltung sperren.
- b) Die Überwachungseinheit
stellt gezielte Fragen an die Logik des Bus-Controllers, die für die Offset-Anwendung,
bei FlexRay beispielsweise während
der Network-Idle-Time (NIT), zuständig ist. Die Logik muss eine
Antwort an die Überwachungseinheit
zurückliefern.
Die geforderte Antwort muss innerhalb festgelegter Zeitfenster erfolgen.
Die Überwachungseinheit
vergleicht das Ergebnis mit ihren lokal abgespeicherten Antworten, insbesondere
prüft sie,
ob es sich um die richtige Antwort auf die gestellte Frage handelt.
Damit wird die korrekte Funktion der Offset-Anwendung vorzugsweise
periodisch überprüft. Permanente Störungen und
die daraus resultierenden Fehler werden detektiert. In diesem Fall
muss die Überwachungseinheit
das Senden von Nachrichten durch den lokalen Bus-Controller vermeiden
bzw. eine eventuell vorhandene Freigabeschaltung sperren.
- c) Die Überwachungseinheit
vergleicht einen Microtick-Zähler
(μT-Counter)
des Bus-Controllers vor
der Offset-Korrektur mit dem Mikrotick-Zähler nach der Offset-Korrektur. Diese
Microtick-Zähler werden über die
Schnittstelle zwischen dem Bus-Controller
und der Überwachungseinheit ausgetauscht.
Die Differenz des Microtick-Zählers vor
und nach der Offset-Korrektur muss innerhalb vorab festgelegter
Bereiche liegen. Werden diese Bereiche überschritten und werden keine
Werte geliefert, muss die Überwachungseinheit
das Senden von Nachrichten durch den lokalen Bus-Controller vermeiden
bzw. eventuell vorhandene Freigabeschaltungen sperren.
Bevorzugte
Ausführungsbeispiele
der vorliegenden Erfindung können
den Unteransprüchen
entnommen werden. Bevorzugte Ausführungsbeispiele der Erfindung
und weitere Vorteile der Erfindung werden anliegend anhand der Figuren
näher erläutert. Es
zeigen:
1 ein
erfindungsgemäßes Kommunikationssystem
gemäß einer
bevorzugten Ausführungsform;
2 ein
aus dem Stand der Technik bekannter Teilnehmer eines Kommunikations-Systems; und
3 einen
erfindungsgemäßen Teilnehmer des
FlexRay-Kommunikationssystems aus 1.
Beschreibung
der Ausführungsbeispiele
Die
vorliegende Erfindung wird nachfolgend beispielhaft anhand eines
FlexRay-Kommunikationssystems
erläutert.
Selbstverständlich
kann die vorliegende Erfindung jedoch auch in anderen Kommunikationssystemen
eingesetzt 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 1 ist
eine vereinfachte Topologie eines FlexRay-Kommunikationssystems
in seiner Gesamtheit mit dem Bezugszeichen 1 bezeichnet.
Das Kommunikationssystem 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 Teilnehmer 3 angeschlossen, die auch als Steuergeräte oder
Hosts bezeichnet werden. Streng genommen umfasst der Host jedoch
noch einen Mikrocontroller, der in 1 mit dem
Bezugszeichen 4 bezeichnet ist. Somit bilden der Teilnehmer 3 und
der Mikrocontroller 4 gemeinsam den eigentlichen Host 5.
Die
Teilnehmer 3 des Kommunikationssystems umfassen jeweils
einen Kommunikations-Controller 6,
der über
den Datenbus 2 zu übertragenden 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 Bus-Treiber 8 des Teilnehmers 3 übertragen,
der sie in eine für
die Übertragung über den
Datenbus erforderliche Form, ebenfalls gemäß der verwendeten Protokoll-Spezifikation,
bringt.
Um
beispielsweise in sicherheitsrelevanten Applikationen des Kommunikationssystems 1 ein blockierendes
Datenbusses 2 durch einen defekten, ständig sendenden Teilnehmer 3 zu
verhindern, sind in den Teilnehmern 3 Buswächter 9 (Bus-Guardian) vorgesehen,
welche die Zugriffsberechtigung der Bus-Treiber 8 ü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 Enable-Signal 10 erhalten.
Das
FlexRay-Kommunikationssystem 1 aus 1 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 einen Active-Star, in der Datenbus-Struktur 2 anzuordnen.
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 bekannten Überwachungs-Konzept taktet ein
Makrotick (MT) 13 des lokalen Kommunikations-Controllers 6 seinen
lokalen Bus-Guardian 9. Der Zeitschlitz mit Sendeaktivität wird zusätzlich durch
ein ARM-Signal 14 des
Kommunikations-Controllers 6 angezeigt. 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 (nicht
dargestellt) auch mit höherer Auflösung überwacht.
Bei
dem Teilnehmer 3 mit dem bekannten Überwachungs-Konzept leitet
der Bus-Guardian 9 also seine Zeitbasis von dem korrigierten
Makrotick-Signal 13 ab, das er von dem Kommunikations-Controller 6 erhält. Das
ARM-Signal 14 dient zur Synchronisation des Beginns eines
Kommunikationszyklus bzw. der Sendeschlitze des Kommunikationszyklus.
Der RC-Oszillator 15 erlaubt 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 (MT)-Signal 13. Durch die Überwachung
dieses Signals 13 mittels der Signale des RC-Oszillators 15 kann
eine vollständige
Unabhängigkeit
von der Zeitbasis des Kommunikations-Controllers 6 nicht
erzielt werden.
Der
Kommunikations-Controller 6 empfängt zu überragende Daten von dem Hostrechner
(Mikrocontroller) 4. Der Controller 6 bringt die
Daten in das gemäß FlexRay-Protokollspezifikation
vorgeschriebene Datenformat. Insbesondere werden die Daten in ein
Nutzdaten-Segment
(sog. Payload Segment) eines Datenrahmens (FlexRay-Frame) eingebracht. Die über den
Datenbus 2 zu übertragenden
formatierten Daten sind in 2 mit dem
Bezugszeichen 16 bezeichnet. Die Daten 16 werden
an den Bus-Treiber 8 übermittelt,
der sie in ein für
die Datenübertragung geeignetes Format bringt. Der Bus-Treiber 8 legt
die zu übertragenden
Daten 16 dann zum Übertragungszeitpunkt
an den Datenbus 2 an. Die Tätigkeit des Bus-Treibers 8 wird
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 und
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 gemäß Kommunikations-Schedule
anderen Sendezeitschlitze der übrigen
Teilnehmer 3 des Kommunikationszyklus. 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
zur Uhrenkorrektur des Kommunikations-Controllers 6 fehlerbehaftet
und unentdeckt sind, driftet der lokale Kommunikations-Controller 6 und
damit auch der lokale Bus-Guardian 9 im Vergleich zum restlichen
Kommunikationsnetzwerk 1. 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 korrgiert
werden. Die nachfolgende Kommunikations-Runde beginnt 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.
Ein
erfindungsgemäßer Teilnehmer 3 ist
im Detail in 3 dargestellt. In dem erfindungsgemäßen Teilnehmer 3 ist
der Bus-Guardian 9 schaltungstechnisch und funktional gegenüber einem
bekannten FlexRay-Bus-Guardian (vgl. 2) derart
erweitert worden, dass selbst permanente Störungen des FlexRay-Kommunikations-Controllers 6 beim
Zugriff auf den Datenbus 2 sicher und zuverlässig detektiert und
entsprechende Abhilfe- und Gegenmaßnahmen unternommen werden
können.
Die erfindungsgemäß vorgeschlagene
Lösung
ist besonders einfach und kostengünstig realisierbar, aber gleichzeitig äußerst wirkungsvoll.
Zwischen
dem Bus-Guardian 9 und dem Kommunikations-Controller 6 ist
eine Schnittstelle 18 angeordnet, die beispielsweise als
eine SPI (Serial Peripheral Interface)-Schnittstelle ausgebildet
ist. Über
diese Schnittstelle 18 kann der Bus-Guardian 9 gezielt
Fragen an den Kommunikations-Controller 6 übertragen
und kann der Kommunikations-Controller 6 auf die Fragen
berechnete Antworten wieder zurück
an den Bus-Guardian 9 übermitteln. Über die Schnittstelle 18 lässt sich
also eine Frage-Antwort-Kommunikation zwischen dem Bus-Guardian 9 und
dem Kommunikations-Controller 6 realisieren. Dazu ist es
erforderlich, dass in dem Bus-Guardian 9 eine Liste 19 mit
verschiedenen Fragen und eine Liste 20 mit den entsprechenden
richtigen Antworten auf die Fragen aus der Liste 19 abgespeichert
sind. Selbstverständlich
können
die Listen 19 und 20 auch zu einer gemeinsamen
Liste zusammengefasst sein. Die Listen 19 und 20 können auch
auf einem Speicher außerhalb
des Bus-Guardian 9 abgespeichert sein, wobei dann bei Bedarf
Fragen und/oder Antworten in den Bus-Guardian 9 übertragen
werden.
Des
Weiteren müssen
in dem Bus-Guardian 9 Mittel 21 vorgesehen sein,
um zu bestimmten Zeitpunkten, vorzugsweise periodisch, eine Frage-Antwort-Kommunikation
zu initiieren. Zur zeitlichen Koordination der Frage-Antwort-Kommunikation
kann das Makrotick (MT)-Signal 13 des Kommunikations-Controllers 6 und/oder
ein Taktsignal des RC-Oszillators herangezogen werden. Selbst wenn das
MT-Signal 13 driftet, weil bspw. die Uhrensynchronisation
in dem Kommunikations-Controller 6 fehlerhaft arbeitet,
und somit ein Fehler des Controller 6 vorliegt, kann dieser
Fehler mit der vorliegenden Erfindung allein durch die Frage-Antwort-Kommunikation detektiert
werden, da der Kommunikations-Controller 6 idealerweise
ein falsches Ergebnis oder ein richtiges Ergebnis, aber außerhalb
des zulässigen
Antwort-Fensters liefern wird. Die Wirksamkeit des Verfahrens hängt entscheidend
von der Art der gestellten Fragen ab. Diese müssen auf die zu überwachende
Komponente und/oder Funktion des Kommunikations-Controllers 6 abgestimmt
sein. Alle zu überwachenden
Komponenten/Funktionen müssen
durch die Fragen abgedeckt sein. Ein Defekt der Komponente/Funktion
muss auch tatsächlich
zu einer fehlerhaften Antwort führen.
Zu
Beginn einer Frage-Antwort-Kommunikation wird aus der Liste 19 eine
geeignete Frage ausgesucht. Die Fragen können entweder nach dem Zufallsprinzip
oder aber in einer vorgegebenen Reihenfolge, beispielsweise in der
Reihenfolge wie sie in der Liste 19 abgelegt sind, aus
der Liste 19 entnommen werden. Bestimmte Frage- und Antwort-Kombinationen
sind zum Erkennen bestimmter Fehler des Kommunikations-Controllers 6 geeignet.
Durch die gezielte Auswahl bestimmter Fragen können also bestimmte Funktionen
und/oder Eigenschaften des Kommunikations-Controllers 6 auf
ordnungsgemäßes Funktionieren
geprüft
werden. Erfindungsgemäß umfassen
die Listen 19 und 20 solche Fragen und Antworten,
die ein Erkennen folgender Fehler ermöglichen:
- a)
Fehler des Input-Sets (der tatsächlich
herangezogenen Synchronisationsnachrichten, Sync-Frames) für die Uhrensynchronisation,
- b) fehlerhafte Berechnung der Rate-Korrektur,
- c) fehlerhafte Anwendung von korrekt berechneten Rate-Korrektur-Werten,
- d) fehlerhafte Berechnung der Offset-Korrektur, und
- e) fehlerhafte Anwendung von korrekt berechneten Offset-Korrektur-Werten.
Nach
der Auswahl einer geeigneten Frage aus der Liste 19 wird
diese über
die Schnittstelle 18 an den Kommunikations-Controller 6 übermittelt. Gleichzeitig
starten die Mittel 21 in weiteren Mitteln 22 zum Überprüfen der
Antwort einen Zeitgeber (Timer) für ein Zeitfenster, innerhalb
dem die Antwort von einem ordnungsgemäß funktionierenden Kommunikations-Controller 6 eingehen
muss. Die Einhaltung dieses Zeitfensters wird durch die Mittel 22 überwacht.
Falls innerhalb des Zeitfensters eine Antwort von dem Kommunikations-Controller 6 eingeht,
wird diese Antwort in den Mitteln 22 auf ihre Richtigkeit
hin überprüft. Dazu
vergleichen die Mittel 22 die eingegangene Antwort mit
der richtigen Antwort aus der Liste 20. Nur wenn die richtige
Antwort innerhalb des definierten Zeitfensters eingeht, gibt der
Bus-Guardian 9 den Zugriff auf den Datenbus 2 durch
das Enable-Signal 17 frei.
Die
von dem Bus-Guardian 9 an den Kommunikations-Controller 6 gestellten
Fragen können beispielsweise
eine oder mehrere der nachfolgenden Fragen umfassen:
- – Anzahl
der von dem Kommunikations-Controller 6 empfangenen, dekodierten
und zur Synchronisation der lokalen Zeitbasis herangezogenen Synchronisationsnachrichten
(Sync-Frames)?
- – Sind
die Anzahl und Identifikation der über die beiden Kommunikationskanäle (Leitungen)
des Datenbus 2 redundant übertragenen Synchronisationsnachrichten
gleich?
- – Zu
welchem Ergebnis kommt die Rate-Korrektur- bzw. Offset-Korrektur-Berechnung
in dem Kommunikations-Controller 6? (Die richtige Antwort
liefert eine in dem Bus-Guardian 9 ausgebildete zusätzliche
Logik zur Berechnung der Rate-Korrektur bzw. Offset-Korrektur, welche
eine identische Umsetzung des Mechanismus aus dem Kommunikations-Controller 6 ist.)
- – Ist
der von dem Mechanismus des Kommunikations-Controllers 6 berechnete
Wert der Rate-Korrektur bzw. der Offset-Korrektur gleich dem in
einem Speicherelement, insbesondere in einem Speicherregister, des
Kommunikations-Controllers 6 abgelegten Korrekturwert?
- – Liegt
die Anzahl der Mikroticks (μT)
pro Makrotick (MT) oder die Anzahl der Mikroticks (μT) pro Kommunikationsrunde
(sog. Communication Cycle) am Ende einer Runde noch unterhalb eines
vorgebbaren Grenzwertes?
- – Liegt
die Differenz eines Mikrotick-Zählers
(μT) vor
der Offset-Korrektur und danach noch innerhalb eines vorgebbaren
Bereichs?
Damit
der Bus-Guardian 9 diese Fragen beantworten kann, müssen zum
Teil zusätzliche
Informationen von dem Kommunikations-Controller 6 zu dem
Bus-Guardian 9 über
die Schnittstelle 18 übermittelt
werden. Diese zusätzlich
zu übermittelnden Informationen
sind beispielsweise:
- – Das Ergebnis der Berechnung
der Rate-Korrektur bzw. der Offset-Korrektur,
- – die
Anzahl der Mikroticks (μT)
pro Kommunikationsrunde bzw. die Anzahl der Mikroticks (μT) pro Makrotick
(MT) am Ende einer Kommunikationsrunde,
- – der
Stand eines Mikrotick (μT)-Zählers des Kommunikations-Controllers 6 vor
der Offset-Korrektur und danach.