-
Die
folgende Erfindung betrifft eine sichere Anbindung eines Kommunikationscontrollers
und insbesondere eines FlexRay-Controllers für sicherheitsgerechte
Anwendungen.
-
Moderne
Verkehrsmittel benötigen sicherheitsrelevante Bussysteme
und Kommunikationssysteme zur Ansteuerung und Überwachung
verschiedenster Komponenten. Ein Beispiel ist das FlexRay-Kommunikationssystem.
-
Sicherheitsrelevante
Kommunikationssysteme sind beispielsweise aus
DE 102 43 713 B4 als redundante
Steuergeräteanordnung,
EP 1 672 505 A2 mit ausfallsicheren Knoten
und
DE 102 11 279
A1 und
DE
102 11 280 A1 als verteilte Systeme bekannt. Verteilte
Kommunikationssystem sind ebenfalls in
WO 2008/010141 A1 beschrieben.
-
Das
FlexRay-Kommunikationssystem stellt ein schnelles deterministisches
und fehlertolerantes Bussystem vorwiegend für den Einsatz
im Automobil-Bereich dar. Ein FlexRay-Controller wird in einer Prozessor-Plattform
wie beispielsweise einem Mikrocontroller integriert. Diese Plattform
weist in der Regel eine bestimmte Sicherheitsstufe auf, die auf
den Eigenschaften der in Hardware und Software realisierten Sicherheitsmaßnahmen
beruht. Seinerseits implementiert ein FlexRay-Controller die für
das FlexRay-Protokoll vorgegebenen Sicherheitsmechanismen zur Fehlererkennung.
Beim Zusammenwirken von Sicherheitsmerkmalen einer Prozessor-Plattform mit
den Sicherheitsmechanismen des FlexRay-Protokolls können
jedoch Sicherheitslücken entstehen, wobei eine Übertragung
von inkonsistenten Daten über den Flex-Ray-Bus nicht erkannt
wird.
-
Vor
diesem Hintergrund wird ein Kommunikationscontroller und insbesondere
einen FlexRay-Controller vorgeschlagen, der so an eine Prozessor-Plattform
angebunden werden kann, dass ein sauber koordiniertes Abschalten
des Kommunikationscontrollers mit Vermeidung von Sicherheitslücken ermöglicht
wird. Diese Anbindung soll auch eine hohe Flexibilität
bieten, so dass verschiedene Abschaltszenarien durch Konfiguration
des Kommunikationscontrollers unterstützt werden.
-
Ein
Aspekt der vorliegenden Erfindung betrifft daher einen Kommunikationscontroller,
und insbesondere einen FlexRay-Controller, der einen Abschaltzustand
umfasst, welcher durch einen Fehler in dem ihm zugeordneten Prozessrechner
oder Mikrocontroller ausgelöst wird. In dem Abschaltzustand stellt
der Kommunikationscontroller die Kommunikation mit dem ihm zugeordneten
Prozessrechner oder Mikrocontroller ein, da der Prozessrechner fehlerhaft ist
und daher möglicherweise fehlerhafte oder inkonsistente
Daten erzeugt, die nicht weitergeleitet werden dürfen.
Typischerweise ignoriert der Kommunikationscontroller im Abschaltzustand
die vom Prozessrechner an den Kommunikationscontroller abgegebenen
Daten. Im Abschaltzustand prüft dann der Kommunikationscontroller,
ob vom Prozessrechner bzw. der von ihm gebildeten Prozessorplattform
vorgegebene Sicherheitsrichtlinien ein synchrones Abschalten der
Datenkommunikation zu anderen Knoten des Kommunikationssystems gestatten
oder ob die Datenkommunikation sofort abgeschaltet werden muss.
Synchron bedeutet in diesem Fall, dass das Abschalten am Ende eines
Kommunikationszyklus erfolgt. Ein synchrones Abschalten ist beispielsweise dann
erforderlich, wenn ein abruptes Ab schalten der Datenkommunikation
zu Störungen anderer Kommunikationsknoten führen
könnte. Dies ist insbesondere dann der Fall, wenn der fehlerbehaftete
Knoten ein Synchronisationsknoten im Kommunikationssystem ist.
-
Der
Kommunikationscontroller kann somit die Kommunikation zu Kommunikationscontrollern anderer
Knoten aufrecht erhalten, beispielsweise um eine Synchronisation
des gesamten Kommunikationssystems nicht zu stören. Dazu
erzeugt und überträgt der Kommunikationscontroller
geeignete Daten, die von anderen Kommunikationscontrollern außer zum
Zwecke der Synchronisation ignoriert werden. Beispielsweise können
die Daten erkennbar so verfälscht sein, dass diese von
den anderen Kommunikationscontrollern verworfen werden. Es ist auch möglich,
Leerdaten, beispielsweise NULL-Bytes, zu senden.
-
Während
des Abschaltzustands kann der Kommunikationscontroller den fehlerhaften
Zustand seines Knotens, d. h. seines Prozessrechners, anderen Kommunikationsknoten
mitteilen. Dazu können beispielsweise geeignete Netzwerkmanagementbotschaften
gesendet werden.
-
Schließlich
ist es möglich, dass sich an den Abschaltzustand ein Wiederherstellungszustand
anschließt. In diesem wird nach einem vorgegebenen Prüfschema
geprüft, ob der Prozessrechner wieder fehlerfrei arbeitet.
Der Wiederherstellungszustand kann beispielsweise durch eine Anfrage
seitens des Prozessrechners eingeleitet werden. Es ist jedoch auch
möglich, dass der Kommunikationscontroller Wiederherstellungsanfragen
an den Prozessrechner in beispielsweise vorgegebenen Zeitintervallen
sendet. Die Wiederherstellung ist insbesondere für fehlertolerante
Systeme geeignet.
-
Es
wird daher gemäß einer Ausführungsform ein
Kommunikationsprotokoll für einen Kommunikationscontroller
bereitgestellt, das einen beispielsweise extern initiierbaren Abschaltzustand umfasst,
in welchem der Kommunikationscontroller die Kommunikation mit dem
ihm zugeordneten fehlerbehafteten Prozessrechner unterbindet und
nach einem gegebenen Algorithmus prüft, ob ein synchrones
Abschalten der Datenkommunikation zu anderen Kommunikationsknoten
möglich ist. Während dieser Zeit werden weiterhin
Daten zur Synchronisation gesendet, die inhaltlich von anderen Kommunikationsknoten
jedoch verworfen werden. Das Kommunikationsprotokoll umfasst weiterhin
einen Wiederherstellungszustand zur Wiederherstellung der Kommunikation
mit dem Prozessrechner.
-
Die
Grundprinzipien der Erfindung werden an Hand des FlexRay-Kommunikationssystems
und des FlexRay-Controllers beschrieben, ohne darauf beschränkt
zu sein.
-
Im
Sinne des Sicherheitskonzepts oder Sicherheitsrichtlinien einer
Prozessor-Plattform kann beispielsweise ein Abschalten der Datenübertragung über
einen FlexRay-Bus angefordert werden, sobald ein sicherheitskritischer
Fehler in der Prozessor-Plattform erkannt wird. Aus Protokollsicht
ist jedoch ein sauber koordiniertes Abschalten der Datenübertragung
sehr erwünscht, um dadurch keine Störungen bei
den anderen Netzwerkknoten zu verursachen. Dies trifft insbesondere
für Synchronisationsknoten zu, da deren abruptes Abschalten
einen Zusammenbruch der Datenübertragung über
einen FlexRay-Bus hervorrufen kann. In fehlertoleranten Prozessor-Architekturen
kann die Sequenz von Abschalten und Wiederaufschalten auch zu Störungen führen.
Falls der FlexRay-Controller nach Erkennung eines Fehlers in einer
fehlertoleranten Prozessor-Architektur nicht abgeschaltet wird,
können inkonsistente Daten in einem kurzen unsicheren Zeitintervall gesendet
werden.
-
Weiterhin
können Sicherheitsarchitekturen unterschiedlich hinsichtlich
des Abschaltens der FlexRay-Datenkommunikation ausgelegt werden. Ein
Sicherheitskonzept bzw. eine Sicherheitsrichtlinie kann ein sofortiges
Abschalten der FlexRay- Datenkommunikation als Folge eines erkannten
sicherheitsrelevanten Fehlers anfordern, während das Abschalten
in vorgegebenen Netzen nur am Ende eines vollständigen
FlexRay-Zyklus stattfinden sollte. Hinzu kommt die Anforderung von
fehlertoleranten Sicherheitsarchitekturen, wonach die Wiederherstellung
eines sicheren Zustandes als abschließender Vorgang bei
der Beherrschung einer Fehlersituation erfolgen muss.
-
Die
hier vorgestellte Erweiterung des Kommunikationscontrollers ermöglicht
es, diese Anforderungen zumindest teilweise oder sogar vollständig
zu erfüllen, wobei eine ausreichend hohe Flexibilität
erreicht wird, um verschiedenen Sicherheitsanforderungen gerecht
zu werden.
-
Gemäß einer
Ausführungsform umfasst das Bereitstellen eines Kommunikationsknotens,
der mit einem Bussystem, insbesondere einem FlexRay-Bussystem, eines
Kommunikationssystems eines Verkehrsmittels in Verbindung steht,
wobei der Kommunikationsknoten wenigstens einen Prozessrechner mit
vorgebbaren Sicherheitsrichtlinien und einen Kommunikationscontroller,
insbesondere einen FlexRay-Controller, aufweist. Bei Auftreten eines Fehlers
im Prozessrechner unterbricht der Kommunikationscontroller die Kommunikation
zum Prozessrechner und prüft, ob die Sicherheitsrichtlinien
ein synchrones Abschalten der Kommunikation zum Kommunikationssystem
ermöglichen oder ein sofortiges Abschalten erfordern, und
ob eine Wiederherstellung der Kommunikation zwischen Kommunikationscontroller
und Prozessrechner gestattet ist.
-
Bei
dem Verkehrsmittel handelt es sich typischerweise, ohne darauf beschränkt
zu sein, um ein Kraftfahrzeug.
-
Das
Verfahren ermöglicht es dabei, sowohl die Anforderungen
des Kommunikationssystems hinsichtlich eines geordneten Abschaltens
eines Kommunikationsknotens als auch die Sicherheitsanforderungen
des Prozessrechner bzw. des auf dem Prozessrechner imple mentierten
Steuersystems zu berücksichtigen. Insbesondere kann die
Weitergabe von fehlerhaften Daten sofort unterbunden werden, ohne
dass Synchronisationsstörungen im Kommunikationssystem
auftreten. Der Kommunikationscontroller kann hierzu in einen Synchronisationsmodus übergehen,
in welchem nur Synchronisationsdaten gesendet oder empfangen werden.
Unter Synchronisationsdaten werden dabei solche Daten verstanden, die
inhaltlich von anderen Kommunikationsknoten verworfen oder unberücksichtig
bleiben, jedoch für die Synchronisation der Kommunikationsknoten
verwendet werden. Bei den Synchronisationsdaten kann es sich um
erkennbar verfälschte Daten oder Leerdaten, z. B. Null-Bytes,
handeln. Typischerweise werden diese Synchronisationsdaten zumindest
bis zum Ablauf des aktuellen Datentelegrams gesendet. Zusätzlich
oder alternativ können auch Netzwerkmanagementbotschaften
zur Bekanntgabe des fehlerhaften Zustands des Kommunikationsknotens
gesendet werden.
-
Falls
die Sicherheitsrichtlinien die Wiederherstellung der Kommunikation
zum Prozessrechner gestatten, kann wenigstens ein Wiederherstellungsversuch
durchgeführt werden. Dabei kann beispielsweise der Kommunikationscontroller
auf eine Anfrage vom Prozessrechner zur Wiederherstellung warten
oder die Wiederherstellungsbereitschaft des Prozessrechners, beispielsweise
innerhalb von vorgebbaren Zeitintervallen, abfragen. Falls eine
Anfrage zur Wiederherstellung der Kommunikation empfangen wurde
oder der Prozessrechner seine Wiederherstellungsbereitschaft signalisiert
hat, kann wenigstens eine Prüfung zur Wiederherstellung
der Kommunikation zwischen Kommunikationscontroller und Prozessrechner
nach einem vorgebbaren Prüfschema durchgeführt
werden. Das Prüfschema kann beispielsweise das Austauschen
von Prüffragen und Prüfantworten zwischen Prozessrechner
und Kommunikationscontroller umfassen.
-
Gemäß einer
weiteren Ausführungsform wird ein Verfahren zum Betreiben
eines Kommunikationsknotens bereitgestellt. Das Ver fahren umfasst
das Bereitstellen eines Kommunikationsknotens, der mit einem Bussystem,
insbesondere einem FlexRay-Bussystem, eines Kommunikationssystems
eines Verkehrsmittels in Verbindung steht, wobei der Kommunikationsknoten
wenigstens einen Prozessrechner zur Ansteuerung einer Komponente
des Verkehrsmittels, wenigstens eine Überwachungseinrichtung
zur Überwachung des Prozessrechners und wenigstens einen
Kommunikationscontroller, insbesondere einen FlexRay-Controller,
mit wenigstens einer prozessorseitigen Schnittstelle, wenigstens
einer busseitigen Schnittstelle und wenigstens einer Schnittstelle
zur Überwachungseinrichtung aufweist. Weiterhin umfasst
das Verfahren das Überwachen des Prozessrechners durch
die Überwachungseinrichtung; das Senden eines Signals von
der Überwachungseinrichtung an den Kommunikationscontroller, sofern
die Überwachungseinrichtung einen Fehler des Prozessrechners
ermittelt hat; und ein Unterbrechen der Kommunikation zwischen Kommunikationscontroller
und Prozessrechner durch den Kommunikationscontroller. Weiterhin
erfolgt eine Prüfung durch den Kommunikationscontroller
ob ein synchrones Abschalten der Kommunikation zum Kommunikationssystem
möglich ist; sowie eine Prüfung durch den Kommunikationscontroller
ob eine Wiederherstellung der Kommunikation zwischen Kommunikationscontroller
und Prozessrechner gestattet ist.
-
Der
Kommunikationskontroller weist demnach mindestens drei Schnittstellen
auf, eine zum Prozessrechner, eine zur Überwachungseinheit
und eine zum Bussystem bzw. Bustreiber.
-
Gemäß einer
weiteren Ausführungsform wird ein Kommunikationsprotokoll,
insbesondere ein FlexRay-Kommunikationsprotokoll, für einen
Kommunikationscontroller eines Kommunikationsknotens, der mindestens
einen Prozessrechner und mindestens einen dem Prozessrechner zugeordneten
Kommunikationskontroller umfasst, bereitgestellt. Das Kommunikationsprotokoll
definiert die Kommunikation mit einem Kommunikationssystem eines
Verkehrsmittels und umfasst einen beispielsweise extern initiierbaren Abschaltzustand,
in welchem der Kommunikationscontroller die Kommunikation mit dem
ihm zugeordneten fehlerbehafteten Prozessrechner unterbindet und
nach einem vorgebbaren oder vorgegebenen Algorithmus prüft,
ob ein synchrones oder sofortiges Abschalten der Datenkommunikation
zum Kommunikationssystem erforderlich ist, wobei bis zum eventuellen
synchronen Abschalten der Datenkommunikation der Kommunikationscontroller
in einen Synchronisationsmodus übergeht; und einen Wiederherstellungszustand
zur Wiederherstellung der Kommunikation mit dem Prozessrechner nach
einem vorgegebenen Prüfschema.
-
Gemäß einer
weiteren Ausführungsform wird ein Kommunikationscontroller,
insbesondere ein FlexRay-Controller, zum Anschluss eines Prozessrechners
an ein Kommunikationssystem eines Verkehrsmittels vorgeschlagen,
wobei der Prozessrechner zur Ansteuerung einer Komponente eines
Verkehrsmittels dient. Der Kommunikationscontroller umfasst wenigstens
eine prozessorseitige Schnittstelle; wenigstens eine busseitige
Schnittstelle; und wenigstens eine Schnittstelle zu einer Überwachungseinrichtung,
welche zur Überwachung des Prozessrechners dient, wobei
auf dem Kommunikationscontroller ein Kommunikationsprotokoll zur
Anbindung des Prozessrechners an das Kommunikationssystem implementiert
ist. Das Kommunikationsprotokoll umfasst dabei einen Abschaltzustand,
welcher über ein von der Schnittstelle zur Überwachungseinrichtung
empfangenes Signal initiierbar ist, wobei in dem Abschaltzustand
der Kommunikationscontroller die Kommunikation zum Prozessrechner zumindest
zeitweise unterbricht und der Kommunikationscontroller in einen
Synchronisationsmodus übergeht, sowie weiterhin einen Wiederherstellungszustand
zur Wiederherstellung der Kommunikation mit dem Prozessrechner nach
einem vorgegebenen Prüfschema.
-
Weiterhin
wird gemäß einer Ausführungsform ein
Kommunikationsknoten bereitgestellt.
-
Die
hier beschriebenen Erweiterungen und Verbesserungen berücksichtigen
unterschiedliche Sicherheitsanforderungen von Plattformen, die in
Sicherheitsrichtlinien niedergelegt sind.
-
Die
Sicherheitsmerkmale einer Prozessor-Plattform können unterschiedlich
wie beispielsweise mittels einer Redundanz von Hardwaremodulen oder
durch eine Überwachung der zeitlichen Abfolge von ausgeführten
Operationen realisiert werden. Eine sichere Prozessor-Plattform
kann als ausfallsichere (Failsafe) oder fehlertolerante Architektur implementiert
werden. Nach Erkennung eines sicherheitsrelevanten Fehlers werden
die Ansteuerung der Aktuatorik sowie äußere Datenaustauschkanäle
in einer Failsafe Prozessor-Architektur ausgeschaltet. Dagegen werden
einzelne Fehler in fehlertoleranten Prozessor-Architekturen beherrscht.
In einem FlexRay-Netzwerk unterliegt jeder Kommunikationsknoten
zusätzlichen Anforderungen, die in Widerspruch zu den Sicherheitsanforderungen
der entsprechenden Prozessor-Architektur stehen können.
Beispielsweise kann ein Knoten eine ausfallsichere (failsafe) Architektur
beinhalten und gleichzeitig anderen Teilnehmern eines Netzwerks
eine Zeitbasis zur Verfügung stellen. Falls ein solcher
Synchronisationsknoten aufgrund eines Fehlers in der eigenen ausfallsicheren
(failsafe) Architektur plötzlich abgeschaltet wird, kann
die Datenübertragung zwischen den restlichen Knoten gestört
werden. Ein solches Störverhalten steht nicht im Einklang
mit den Anforderungen für das standardisierte FlexRay-Protokoll.
Wenn die FlexRay-Datenübertragung nach einem Fehler in
einer ausfallsicheren (failsafe) Prozessor-Architektur nicht abgebrochen
wird, besteht die Möglichkeit der Übertragung
von inkonsistenten Daten. In einer fehlertoleranten Prozessor-Architektur
wird eine Fehlererkennung in der Regel von einer kurzen unsicheren Zeit
gefolgt. Während dieser kurzen unsicheren Zeit können
inkonsistente Daten fehlerfrei über einen FlexRay-Bus gesendet
werden, so dass der auftretende Fehler von keinem anderen FlexRay-Knoten erkannt
wird.
-
Weitere
Einzelheiten, Merkmale und Vorteile der vorliegenden Erfindung ergeben
sich aus der folgenden Beschreibung und Zeichnungen von Ausführungsformen.
In den Zeichnungen zeigen:
-
1 Verwendungsfälle
(Use Cases) von FlexRay-Prozessen mit einer Erweiterung um einen zusätzlichen
Abschaltpfad;
-
2 Anbindung
eines FlexRay-Controllers in einer asymmetrischen ausfallsicheren
(failsafe) Prozessorarchitektur;
-
3 Anbindung
eines FlexRay-Controllers in einer integrierten symmetrischen ausfallsicheren (failsafe)
Prozessorarchitektur;
-
4 Anbindung
eines FlexRay-Controllers in einer ausfallsicheren (failsafe) Prozessorarchitektur
mit Watchdog Überwachung;
-
5 Anbindung
eines FlexRay-Controllers in einer dreifachredundanten Prozessorarchitektur;
-
6 Abschaltablauf
eines FlexRay-Controllers nach Auftreten eines sicherheitsrelevanten Fehlers
in einer Prozessorarchitektur;
-
7 Erfindungsgemäße
Erweiterung der internen Zustände eines FlexRay-Controllers.
-
In 1 stellt
das Diagramm 1 die Verwendungsfälle (Use Cases)
von FlexRay-Prozessen auf Basis der FlexRay-Spezifikation dar (Siehe „FlexRay Requirements
Specification Version 2.1" Spezifikation, Kapitel 8, Absatz
8.1: Use Case Diagram for FlexRay Processes). In diesem
Diagramm kann ein hier als Hostprozessor bezeichneter Prozessrechner oder
Mikrocontroller das Abschalten einer FlexRay-Datenübertragung
(Prozess: Shutdown Communication Module) anfordern. Dieses Diagramm wird
nun um eine zusätzliche Steuerfunktion 2 erweitert,
die den Abschaltprozess 3 in sicherheitsgerichteten Prozessorarchitekturen
an stoßen kann. In herkömmlichen Anbindungen von
FlexRay-Controllern ist diese Erweiterung nicht enthalten. Die FlexRay-Spezifikation „FlexRay
Communications system – Protocol Specification Rev 2.1
A" setzt in Absatz 2.2.1.2 voraus, dass ein Abschaltvorgang
von einem FlexRay-Controller durch folgende Ursachen hervorgerufen
werden kann:
- – Produktspezifischer
Fehler (z. B. BIST Fehler, Sanity checks)
- – Ein vom Hostprozessor erkannter Fehler oder
- – Ein fataler Fehler, der durch interne Mechanismen
des FlexRay-Controllers erkannt wird.
-
Diese
Implementierung reicht nicht für sicherheitsgerichtete
Mikrocontroller-Plattformen aus. Daher wird gemäß einer
Ausführungsform vorgeschlagen, dass eine Überwachungseinrichtung,
beispielsweise ein anderer Prozessor als externes Produkt, den Abschaltvorgang
des FlexRay-Controllers eines unabhängigen Mikrocontrollers
einleiten kann. Der FlexRay-Controller kann dazu mit einer weiteren Schnittstelle
ausgerüstet werden. Hierbei kann es sich bevorzugt um eine
hardwaremäßige Schnittstelle handeln.
-
In 2 wird
eine asymmetrische redundante Sicherheitsarchitektur veranschaulicht.
Ein Kommunikationsknoten weist einen Hauptmikrocontroller 10,
der hier die Funktion des Prozessrechners übernimmt, auf.
Der im Hauptmikrocontroller 10 integrierte FlexRay-Controller 12 wird
vom Hostprozessor 11 konfiguriert und verwendet. Als eigenständiges
Produkt stellt der Hauptmikrocontroller 10 einen im Sinne der
FlexRay-Spezifikation vollständigen FlexRay-Knoten dar.
-
Der
Hauptmikrocontroller 10 wird von einem anderen Mikrocontroller 13,
der hier die Funktion der Überwachungseinheit übernimmt, überwacht.
Als externes Produkt kann der Überwachungsmikrocontroller 13 Fehler
erkennen, die von den im Mikrocont roller 10 implementierten
Diagnosefunktionen nicht erfasst werden. Der Mikrocontroller 13 weist
dazu ebenfalls einen Hostprozessor 14 auf.
-
Für
die Überwachung werden beispielsweise die gleichen Eingangssignale 111 in
die zwei Mikrocontroller 10 and 13 eingespeist.
Der Hauptmikrocontroller 10 generiert die zu überprüfenden
Signale 161, die beispielsweise von der An- bzw. Abfrageeinheit 16 an
den überwachenden Mikrocontroller 13 gesendet
werden. In der hier dargestellten asymmetrischen redundanten Plattform
wird der überwachende Mikrocontroller 13 das externe
Signal erzeugen, mit dem das Abschalten der FlexRay-Datenübertragung nach
Erkennung eines sicherheitsrelevanten Fehlers initiiert wird. Hierbei
wird beispielsweise das gleiche Abschaltsignal 131 verwendet,
was auch zum Anschalten von sicherheitsrelevanten Ausgängen 15 (wie
beispielsweise für die Aktuatorik) verwendet wird.
-
Der
FlexRay-Controller 12 weist eine prozessorseitige Schnittstelle 17 für
die Kommunikation mit dem Hostprozessor 11 und eine busseitige
Schnittstelle 19 für die Kommunikation mit dem
Bussystem auf. Typischerweise umfasst die busseitige Schnittstelle 19 die Übertragungsleitung
(TX = Transmission; TXEN = Transmission Enable) 122 und
die Empfangsleitung (RX = Reception) 121, die zu einem Bustreiber
führen. Weiterhin weist der der FlexRay-Controller 12 eine
Schnittstelle 18 auf, über die der FlexRay-Controller 12 das
Abschaltsignal 131 vom überwachenden Mikrocontroller 13 erhält.
-
Im
Normalfall sendet der Hauptmikrocontroller 10 die Steuersignale 112 über
den schaltbaren Ausgang 15 an die zu überwachende
Komponente 113. Ausgang 15 wird vom überwachenden
Mikrocontroller 13 gesteuert.
-
Bei
der hier dargestellten Ausführungsform umfasst der Hauptmikrocontroller 10 den
Hostprozessor 11, den FlexRay-Controller 12 und
die Abfrageeinheit 16, die alle in einem gemeinsamen und
hier mit MCU1 (IC1) bezeichneten Chip integriert sind. Der überwachende
Mikrocontroller 13, hier dargestellt als MCU2 (IC2), ist
auf einem separaten Chip integriert, kann jedoch in den Kommunikationsknoten eingebunden
sein.
-
Die
Integration einer Doppelredundanz von Prozessorkernen in einen Chip 20,
hier als MCU3 (IC3) bezeichnet, ist in 3 veranschaulicht.
Die tatsächliche Ansteuerung des FlexRay-Controllers 12 übernimmt
der Prozessorkern 22, während der Prozessorkern 21 zur Überwachung
des anderen Prozessorkerns 22 dient. Der Überwachungsprozessorkern 21 kann
selbstständig die Aktuatorik sowie den FlexRay-Controller 12 im
Fehlerfall abschalten. Dazu ist ein Komparator 25 integriert,
der die Signalausgänge der Prozessorkerne 21 und 22 überprüft und
bei unterschiedlichen Signalen an die Sicherheits- bzw. Überwachungsschnittstelle 18 des
FlexRay-Controllers 12 ein entsprechendes Signal sendet.
Außerdem führt jeder Vergleichsfehler zwischen den
zu überprüfenden Signalen der zwei Prozessorkerne 21, 22 dazu,
dass mittels eines Abschaltsignals 202 neben der FlexRay-Datenkommunikation
auch die Ansteuerung der Aktuatorik durch Unterbrechen des Ausgangs 15 abgeschaltet
wird.
-
Es
ist auch möglich, dass Prozessorkern 22 die Steuerung übernehmen
kann, wenn der Prozessorkern 21 ausgefallen ist. Die Steuersignale 112 werden
von einem Treiber 23 abgegeben.
-
4 zeigt
die gleiche Architektur wie 3 mit einer
Erweiterung um eine zusätzliche Überwachungskomponente 31,
die eine Watchdog-Funktion ausführt und die Signalleistung
von analogen Schaltkreisen aufbereitet. Die Watchdog-Funktion wird
von einer Watchdog-Einheit 32 ausgeführt, welche
einen eigenen Zeitgeber aufweist. Dadurch kann geprüft werden,
ob die Signale auch zeitrichtig erzeugt werden. Somit lassen sich
neben inhaltlichen Fehlern, die vom Komparator 25 erkannt
werden, auch Zeitfehler ermitteln. Die Steuersignale 301 werden
vom Treiber 34 erzeugt und in die Watchdog-Einheit 32 gegeben.
Im Fehlerfall gibt die Leistungsstufe der Überwachungskomponente 31 ein
entsprechendes Abschaltsignal 402 an den Ausgang 15.
Die Überwachungseinheit wird hier durch einen der beiden
Prozessorkernen 21, 22, dem Komparator 25 und
die Watchdog-Einheit 32 gebildet.
-
Das
von der Watchdog-Einheit 32 abgegebene Abschaltsignal 302 wird
in einer Vergleichseinheit 26 mit dem Abschaltsignal 202 des
Komparators 25 verglichen. Zeigt eines der beiden Abschaltsignale einen
Fehler an, wird ein entsprechendes Abschaltsignal an die überwachungsseitige
Schnittstelle 18 des FlexRay-Controllers 12 abgegeben.
-
Die
Prozessorkerne 21, 22, Komparator 25, FlexRay-Controller 12,
Vergleichseinheit 26 und Treiber 34 sind im hier
dargestellten Ausführungsbeispiel in einen als MCU4 (IC4)
bezeichneten Chip integriert. Diese Einheit bildet den Mikrocontroller
eines Knotens. Die Überwachungskomponente 31 ist
hier extern gezeigt, kann aber ebenfalls integriert sein.
-
Eine
dreifache Redundanz von in einen Chip 50, hier als MCU5
(IC5) bezeichnet, integrierte Mikroprozessorkernen 51, 52 und 53 wird
in 5 veranschaulicht. Die Ansteuerung des Flex-Ray-Controllers 12 erfolgt
durch einen der drei Mikroprozessorkerne 51, 52 oder 53.
Die anderen Prozessorkerne überwachen den für
die FlexRay-Datenübertragung aktiven Prozessorkern. Falls
ein sicherheitsrelevanter Fehler auftritt, wird der betroffene Prozessorkern mittels
der vorhandenen Mehrheitsentscheidung 54 ermittelt. Wenn
der aktive Prozessorkern als betroffen identifiziert wird, übernimmt
ein anderer Prozessorkern die FlexRay-Datenübertragung.
Hierfür wird zuerst ein Mechanismus zur Übergabe
der Ansteuerung des FlexRay-Controllers 12 eingeleitet.
Der Mehrheitsvoter 54 erzeugt die Abschaltsignale für den
Flex-Ray-Controller 12 und den Ausgang 15. Die Überwachungseinheit umfasst
bei dieser Ausführungsform mindestens zwei der drei Prozessorkerne sowie
den Mehrheitsvoter 54.
-
Der
Abschaltablauf eines FlexRay-Controllers ist in 6 illustriert.
Nachdem in Schritt 301 ein sicherheitsrelevanter Fehler
ermittelt wurde, geht der FlexRay-Controller in einen Abschaltzustand über, wobei
in Schritt 304 überprüft wird, ob die
vorhandene Konfiguration, d. h. die vorgegebenen Sicherheitsrichtlinien,
ein sofortiges Abschalten freigibt. In diesem Fall erfolgt in Schritt 303 ein
sofortiges Abschalten der FlexRay-Kommunikation. Andernfalls wird
ein synchrones Abschalten eingeleitet. Wenn kein Fehler auftrat,
verbleibt der Knoten im normalen Betriebszustand in Schritt 302.
-
Im
Fall eines synchronen Abschaltens sollte eine FlexRay-Datenübertragung
erst am Ende eines FlexRay-Zyklus abgeschaltet werden. Wenn der
Fehler während der aktiven Sendephase eines Datentelegramms
(Frame) auftritt, wird der mit dem Fehler behaftete Knoten in Schritt 305 das
Telegramm mit einer falschen CRC-Prüfsumme weiter schicken,
d. h. die Daten werden beispielsweise erkennbar verfälscht.
Bis zum Ende des angehenden Flex-Ray-Zyklus werden dann Datentelegramme
mit Nullbytes als Nutzdaten in den restlichen Sendzeitschlitzen (Transmit
Slots) gesendet. Auf diese Weise werden Daten, die vom mit dem Fehler
behafteten Knoten während dieses unsicheren Zeitintervalls
gesendet werden, von anderen Teilnehmern im Netzwerk verworfen.
Somit kann der mit dem Fehler behaftete Knoten die Synchronisation
im Netzwerk unterstürzen oder befolgen, ohne dass seine
Nutzdaten ein Sicherheitsrisiko für andere Teilnehmer darstellen.
Der FlexRay-Controller befindet sich daher in einem Synchronisationsmodus.
-
Nach
der Fehlererkennung in Schritt 301 wird der FlexRay-Controller
vorzugsweise jeglichen Datenaustausch mit dem entsprechenden Hostprozessor
(Prozessrechner) abbrechen. Die Verbindung zwischen dem FlexRay-Controller
und dem Hostprozessor kann nur nach einer erfolgreichen Wiederherstellung
oder nach einem Reset der ganzen Plattform (Host-Prozessor, FlexRay-Controller)
wieder in Betrieb genommen werden.
-
Am
Ende des aktuellen Zyklus 306 startet der mit dem Fehler
behaftete Knoten in Schritt 307 einen neuen Zyklus, in
dem er seinen fehlerhaften Zustand im Netzwerk bekanntgibt. Hierfür
wird er Netzwerkmanagement-Botschaften (NMV: Network Management
Vectors) in den ihm zugeordneten Zeitschlitzen senden. In Schritt 307 handelt
der FlexRay-Controller vorzugsweise selbstständig, da er
in dieser Phase dem Host-Prozessor nicht trauen kann. Falls keine
Wiederherstellung (Recovery) in der Sicherheitsarchitektur unterstützt
wird, wird die FlexRay-Datenübertragung am Ende des in
Schritt 307 laufenden Zyklus abgeschaltet (310).
Andernfalls werden Versuche zur Wiederherstellung der Verbindung
zwischen dem Host-Prozessor und dem FlexRay-Controller gestartet.
In einer Sicherheitsarchitektur mit dreifacher Redundanz kann beispielsweise eine
Wiederherstellung initiiert werden, nachdem der fehlerhafte Prozessor
ermittelt und funktionell ausgeklammert wurde.
-
Der
FlexRay-Controller geht daher in einen Wiederherstellungszustand über
und versucht, die Kommunikation mit dem Hostprozessor wiederherzustellen.
-
Die
Anzahl der Versuche zur Wiederherstellung der Verbindung zwischen
dem FlexRay-Controller und dem ansteuernden Hostprozessor ist vordefiniert
und kann nur in der Konfigurationsphase des FlexRay-Controllers
geändert werden.
-
Eine
Wiederherstellungsphase wird beispielsweise vom Hostprozessor durch
dafür vorgesehene Signale initiiert. Anschließend
sendet der Hostprozessor dem FlexRay-Controller ein erstes Prüfwort.
Der FlexRay-Controller generiert eine Antwort auf dieses Prüfwort
nach einem vordefinierten Prüfalgorithmus und sendet diese
Antwort und ein anderes Prüfwort zum Hostprozes sor. Nach
einer erfolgreichen Überprüfung der erhaltenen
Antwort sendet der Hostprozessor die Antwort auf das vom FlexRay-Controller
generierte Prüfwort. Dementsprechend überprüft
der FlexRay-Controller die Antwort des Hostprozessors nach dem festgelegten
Prüfwort. Diese gegenseitige Überprüfung
von Prüfwörtern zwischen dem Hostprozessor und
dem FlexRay-Controller bildet einen vollständigen Wiederherstellungsversuch.
Als Pass-Kriterium zur Wiederherstellung wird vorzugsweise eine
bestimmte Anzahl von positiv abgeschlossenen Versuchen in Schritt 313 angefordert.
-
Die
Wiederherstellung kann beispielsweise stattfinden, wenn fünf
aufeinanderfolgende Versuche erfolgreich abgeschlossen werden. Während
die Versuche zur Wiederherstellung in Schritt 313 durchgeführt
werden, sendet ein anderer Prozess NMV (Network Management Vector)
in Schritt 312 weiter. Am Ende des Zyklus (314),
d. h. eines Kommunikationszyklus, wird in Schritt 315 überprüft,
ob die Wiederherstellung erfolgreich abgeschlossen wurde. Je nach
Auslegung des Prüfverfahrens und der Anfangszeit der Überprüfung
kann es vorkommen, dass der Überprüfungsvorgang
am Zyklusende noch nicht abgeschlossen ist. In diesem Fall wird
die Überprüfung für eine Wiederherstellung über
eine vordefinierte Anzahl N von FlexRay-Kommunikationszyklen ausgedehnt
(316, 317). Die Wiederherstellungsversuche werden
abgebrochen und die FlexRay-Kommunikation in Schritt 319 abgeschaltet,
falls die festgelegte Anzahl N von Zyklen in Schritt 316 überschritten
wird. Ansonsten erfolgt eine Wiederherstellung in Schritt 318,
falls die Überprüfungsversuche erfolgreich abgeschlossen
wurden.
-
Mit
den hier beschriebenen Eigenschaften werden neue Zustände
für den FlexRay-Kommunikationscontroller und das zugehörige
Protokoll hinzugefügt werden, um dessen Anbindung in Sicherheitsarchitekturen
zu verbessern. In
7 werden diese neuen Zustände
410 und
420 als
Ergänzung der herkömmlichen Zustände
400 (siehe
FlexRay-Spezifikation
"FlexRay Communications System – Protocol Specification",
Version 2.1, Revision A, Figur 2–3 in Absatz 2.3)
veranschaulicht. Die Zustände
410 und
420 unterscheiden
sich von den anderen Zuständen dadurch, dass die Verbindung
zwischen dem Host-Prozessor und dem FlexRay-Controller getrennt
ist. In diesen Zuständen betrachtet der FlexRay-Controller
weder Daten noch Befehle vom Host-Prozessor, da ein Sicherheitsrisiko
seitens des Host-Prozessors vorhanden ist. Im Zustand
410 wird je
nach Konfiguration entschieden, ob ein Abschalten stattfinden soll.
Ein Abschalten wird über den Pfad
402 erfolgen,
d. h. der FlexRay-Controller geht in den ”Halt”-Zustand,
während der Pfad
403 zum Wiederherstellungszustand
420 führt.
Nach einer erfolgreichen Wiederherstellung führt der Pfad
404 zu
einem normalen Zustand, in dem der FlexRay-Controller Daten und
Befehle des Host-Prozessors wieder betrachtet. Bei misslungener
Wiederherstellung wird der FlexRay-Controller über Pfad
405 ebenfalls
in den ”Halt”-Zustand gebracht.
-
Die
Erfindung ist nicht auf die vorliegend beschriebenen Ausführungsbeispiele
beschränkt, sondern kann geeignet erweitert und modifiziert
werden. Die nachfolgenden Ansprüche stellen einen ersten, nicht
bindenden Versuch dar, die Erfindung allgemein zu definieren.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- - DE 10243713
B4 [0003]
- - EP 1672505 A2 [0003]
- - DE 10211279 A1 [0003]
- - DE 10211280 A1 [0003]
- - WO 2008/010141 A1 [0003]
-
Zitierte Nicht-Patentliteratur
-
- - „FlexRay
Requirements Specification Version 2.1” Spezifikation,
Kapitel 8, Absatz 8.1: Use Case Diagram for FlexRay Processes [0034]
- - „FlexRay Communications system – Protocol Specification
Rev 2.1 A” setzt in Absatz 2.2.1.2 [0034]
- - ”FlexRay Communications System – Protocol Specification”,
Version 2.1, Revision A, Figur 2–3 in Absatz 2.3 [0056]