-
Die
Erfindung betrifft ein Verfahren zur Steuerung und Überwachung
eines sich entlang einer Fahrstrecke bewegenden Fahrzeugs, insbesondere zur
signaltechnisch sicheren Zugbeeinflussung anhand von Vorgaben für sich innerhalb
eines Streckennetzes bewegende Fahrzeuge, gemäß dem Oberbegriff des Anspruchs
1.
-
Zugbeeinflussungssysteme
zur Steuerung und Überwachung
von Fahrzeugen sind bekannt, wobei sich die Fahrzeuge innerhalb
eines Streckennetzes entlang einer Fahrstrecke bewegen. Zur Zugbeeinflussung
befindet sich in den Fahrzeugen ein signaltechnisch sicherer Rechner,
auf dem Anwendungssoftware zur Verarbeitung von als Sensordaten erfassten
Fahrzeugdaten implementiert ist. Beim Erkennen einer Gefahr leitet
der sichere Rechner beispielsweise eine Notbremsung des Fahrzeugs
ein.
-
Sichere
Rechner sind als Mehrrechnersysteme ausgelegt, wobei mittels spezieller
Maßnahmen, beispielsweise
einer mehrkanaligen Verarbeitung und einem Vergleich der Ausgabewerte
sowie einer sicheren Abschaltung im Fehlerfall, das erforderliche Sicherheitsniveau
(beispielsweise Safety Integrity Level SIL > 0 für
ETCS) erreicht wird. Neben einem höheren Hardwareaufwand wird
dabei auch spezielle Software verwendet, um die Rechnersysteme signaltechnisch
sicher zu machen. Die Sicherheitsanforderungen führen dazu, dass stets ein Teil
der Rechenleistung für
notwendige Prüffunktionen
zur Fehleroffenbarung eingesetzt werden muss, so dass die für die Anwendungs software
verfügbare
Rechnerperformance begrenzt ist. Aus diesem Grunde sind die Möglichkeiten
zur Erweiterung von performanceintensiven Anwendungen und Erweiterungen
eingeschränkt.
-
Eine
Möglichkeit,
die Performanceprobleme zu lösen,
besteht darin, signaltechnisch nicht sicherheitsrelevante Aufgaben
in einen signaltechnisch nichtsicheren Rechner auszulagern.
-
Dabei
besteht ein Problem bei der Trennung von sicheren und nichtsicheren
Aufgaben darin, dass Sensordaten parallel genutzt werden müssen, obwohl
die doppelte Anschaltung eines Sensors sensorseitig in der Regel
nicht unterstützt
wird. Auch die Doppelung der Sensoren bringt oftmals Probleme mit sich
und ist außerdem
mit höheren
Kosten verbunden. Damit bleibt in vielen Fällen nur die Möglichkeit, die
Sensoren an den sicheren Rechner anzuschließen und die Sensordaten anschließend über eine Rechnerkopplung
zu verteilen. Bei der Durchleitung der Sensordaten von einem Rechner
zu einem anderen Rechner ist eine Schnittstelle erforderlich, die wiederum
mit Aufwand verbunden ist und Rechnerperformance kostet. Weiter
kann es auch notwendig sein, neben den Sensordaten Prozessdaten
im nichtsicheren Rechner weiterzuverarbeiten. Auch diese Daten müssten über eine
Schnittstelle zwischen den Rechnern ausgetauscht werden und verursachen
so ebenfalls einen entsprechenden Ressourcenverbrauch.
-
Meist
ist zur Systemdiagnose bereits eine (Diagnose-)Schnittstelle zum
Datenaustausch beim sicheren Rechner vorhanden, über die er mit einem nichtsicheren
Rechner verbunden ist. Zur Systemdiagnose ist dabei auf dem sicheren
Rechner eine Diagnose-Policy-Software und auf dem nichtsicheren Rechner
eine Diagnose-Strategy-Software implementiert. Die Diagnose-Policy-Software dient
der Auskopplung von Sensordaten (als auch von Prozessdaten), welche
die Diagnose-Policy-Software auf Anforderung der Diagnose-Strategy-Software über diese
Schnittstelle bereitstellt.
-
Die
Aufgabe der Erfindung ist es, ein Verfahren zur Entlastung des sicheren
Rechners anzugeben, unter der Randbedingung, dass der sichere Rechner
als geprüftes
und zugelassenes unabhängiges
System nicht oder fast nicht verändert
werden kann und darf.
-
Die
Aufgabe wird durch die Merkmale des Anspruchs 1 gelöst; die
Unteransprüche
beinhalten vorteilhafte Ausgestaltungen.
-
Die
Lösung
der Aufgabe sieht vor, dass auf dem nichtsicheren Rechner zusätzlich mindestens eine
Applikation implementiert ist, die Sensordaten/Prozessdaten (vorrangig
Sensordaten und bedarfsweise Prozessdaten) anstelle und zur Entlastung
des sicheren Rechners für
nichtsichere Zwecke verarbeitet, wobei die Sensordaten/Prozessdaten ebenfalls über die
Diagnose-Strategy-Software
bei der Diagnose-Policy-Software angefordert und von dieser über die
(Diagnose-)Schnittstelle bereitgestellt werden. Zweckmäßigerweise
ist im sicheren Rechner mindestens ein Beobachtungspunkt/Tracepunkt vorgesehen,
an dem die Diagnose-Policy-Software die angeforderten Sensordaten/Prozessdaten
auskoppelt.
-
Zur
stärkeren
Entlastung des sicheren Rechners wird vorgeschlagen, dass die Diagnose-Strategy-Software
die Sensordaten/Prozessdaten für
mehrere Applikationen an als Software-Schnittstelle ausgebildeten Tracezugängen der
Diagnose-Strategy-Software bereitstellt.
-
Um
eine Überlastung
des sicheren Rechners durch zu hohe Datenanforderungen zu verhindern, wird
vorgeschlagen, dass die Sensordaten/Prozessdaten, welche die Diagnose-Strategy-Soft ware
anfordert, bereits vor dem Anfordern begrenzt werden, wenn anhand
einer Bewertung festgestellt wird, dass es durch diese Datenanforderungen
zu einer Überlastung
des sicheren Rechners kommen könnte.
-
Zweckmäßigerweise
werden die Bewertung und die Begrenzung durch einen zusätzlich vorgesehenen
Lastmanager durchgeführt.
-
Zur
sicheren Abschätzung
einer möglichen Überlastung
des sicheren Rechners stellt der Lastmanager die Funktionen und
Regeln zur Überwachung
und Begrenzung des aus Sensordaten/Prozessdaten bestehenden Datenübertragungsvolumens
bereit, anhand derer mittels Steuerungsvorgaben/Tracelevel die Datenübertragung
an der (Diagnose-)Schnittstelle gesteuert wird.
-
Das
Verfahren sieht weiterhin im Lastmanager der Diagnose-Strategy-Software
eine zusätzliche Steuerungsschnittstelle
vor, mit der eine applikationsseitige Anforderung des aktuell erforderlichen Datenübertragungsvolumens
erfolgt.
-
Bei
einer Vielzahl von Applikationen auf dem nichtsicheren Rechner lässt sich
die Entlastung des sicheren Rechners vereinfachen, wenn für Applikationen
mit wechselndem/dynamischem Übertragungsbedarf
an Sensordaten/Prozessdaten ein Applikationsmanager vorgesehen ist,
der über
weitere Steuerschnittstellen mit diesen Applikationen und dem Lastmanager
verbunden ist, den aktuellen Bedarf an Datenübertragungsvolumen der angeschlossenen Applikationen
ermittelt, überwacht
und in Überlastsituationen
anhand von vorgegebenen Regeln reduziert sowie den resultierenden
Bedarf der Applikationen als Steuerungsvorgabe an den Lastmanager übermittelt.
-
Die
Erfindung wird nachfolgend anhand einer Zeichnung näher erläutert. Es
zeigen:
-
1 ein
System zur Zugbeeinflussung mit einem sicheren und einem mit diesem
verbundenen nichtsicheren Rechner, und
-
2 ein
System gemäß 1 erweitert durch
einen Applikationsmanager.
-
1 zeigt
ein System zur Steuerung und Überwachung
eines Fahrzeugs, das sich entlang einer Fahrstrecke innerhalb eines
Streckennetzes bewegt.
-
Das
System weist einen in dem Fahrzeug angeordneten signaltechnisch
sicheren Rechner 1 auf, der mit mehreren außerhalb
des Rechners 1 angeordneten Sensoren S (hier S1, S2, S3,
S4) verbunden ist, welche Fahrzeugdaten erfassen und als Sensordaten
an den Eingängen
E (E1, E2, E3, E4) des sicheren Rechners 1 diesem zur weiteren
Verarbeitung zur Verfügung
stellen.
-
Der
sichere Rechner 1 ist zweikanalig mit den beiden identischen
Kanälen
A und B ausgeführt.
-
Auf
den beiden Kanälen
A und B des sicheren Rechners 1, läuft jeweils eine Anwendungssoftware 2,
die aus mehreren Anwendungsprogrammen bestehen kann und die Sensordaten
unter Bildung von Prozessdaten verarbeitet.
-
Weiter
ist auf dem sicheren Rechner 1 eine Diagnose-Policy-Software 3a eines
Diagnosesubsystems 3 vorgesehen, die Zugriff auf nicht
weiter dargestellte Tracepunkte (Beobachtungspunkte) des sicheren
Rechners 1 hat, zu denen die Eingänge E gehören und an welchen die Diagnose-Policy-Software 3a Zugang
zu der rechnerinternen Datenkommunikation hat und an den Beobachtungspunkten vorhandene
Diagnosedaten, also Prozessdaten einschließlich Sensordaten, kopieren
und auskoppeln kann.
-
Die
Auskopplung erfolgt auf Anforderung einer Diagnose-Strategy-Software 3b,
die auf einem unabhängig
vom sicheren Rechner 1 arbeitenden nichtsicheren Rechner 4 implementiert
ist und zusammen mit der Diagnose-Policy-Software 3a ein vollständiges Diagnosesubsystem 3 bildet,
wobei die als Plausibilitätsorakel
arbeitende Diagnose-Strategy-Software 3b anhand der angeforderten
Diagnosedaten eine Systemdiagnose abgibt. Von Orakel kann man hier
deshalb sprechen, weil zur Systembeobachtung immer nur ein kleiner
Teil der Prozessdaten des sicheren Rechners 1 zur Verfügung steht
und aus diesen Daten von der Diagnose-Strategy-Software 3b anhand
von hinterlegten Regeln abzuleiten ist, welche Fehlerzustände im sicheren
Rechner 1 bestehen und welche Diagnosedaten daraufhin angefordert
werden müssen,
um den Fehlerzustand genauer diagnostizieren zu können. Für die Anforderung
der jeweiligen Daten im benötigten
Umfang verfügt
die Diagnose-Strategy-Software 3b über Mechanismen, Tracelevel
(Steuerungsvorgaben für
die Datenübertragungsmenge)
der Tracepunkte zu schalten und damit via Diagnose-Policy-Software 3a mehr oder
weniger Daten aus einem Tracepunkt auszukoppeln
-
Zum
Datenaustausch sind beide Rechner 1, 4 über eine
Hardware-Schnittstelle 5 miteinander verbunden.
-
Die
Diagnosedaten werden jeweils auf Anforderung der Diagnose-Strategy-Software 3b von der
Diagnose-Policy-Software 3a ausgekoppelt und über die
Schnittstelle 5 an die Diagnose-Strategy-Software 3b übergeben.
-
Auf
dem nichtsicheren Rechner 4 läuft zusätzlich und unabhängig von
dem Diagnosesubsystem 3 eine Applikation 6, welche
insbesondere Sensordaten anstelle und zur Entlastung des sicheren Rechners 1 für signaltechnisch
nichtsichere Zwecke verarbeitet, an die geringe bis keine Sicherheitsanforderungen
gestellt werden. Bei Bedarf können
beliebig viele Applikationen 6 im nichtsicheren Rechner 4 implementiert
werden.
-
Die
von der Applikation 6 benötigten Applikationsdaten (insbesondere
Sensordaten) werden unter Ausnutzung des vorhandenen Diagnosesubsystems 3 wie
die Diagnosedaten über
die Diagnose-Strategy-Software 3b bei der Diagnose-Policy-Software 3a angefordert
und über
Tracezugänge T
(hier T1, T2, T3, T4), die als Software-Schnittstellen ausgebildet
sind, der Applikation 6 von der Diagnose-Strategy-Software 3b bereitgestellt.
-
Ein
Lastmanager 7, hier im Ausführungsbeispiel die um eine
Funktionalität
zum Lastmanagement erweiterte Diagnose-Strategy-Software 3b wie in 2 dargestellt,
analysiert die Anforderungen bezüglich
der vom sicheren Rechner 1 zu übertragenen Daten (Diagnosedaten
und Applikationsdaten) und steuert anhand von Tracelevel (Steuerungsvorgaben)
die Datenübertragungsmenge
an der Schnittstelle 5.
-
Lässt sich
anhand der angeforderten Daten einschließlich vorgegebener Tracelevel
eine Überlastung
der Schnittstelle 5 zwischen sicherem und nichtsicherem
Rechner 1, 4 prognostizieren, reduziert der Lastmanager 7 das
angeforderte Gesamtdatenvolumen, so dass eine Überlastung der (Kopplungs-)Schnittstelle 5 vermieden
wird und die Echtzeitfähigkeit
der Datenübertragung
gewährleistet bleibt.
Zu diesem Zweck verwaltet der Lastmanager 7 Regeln, mit
denen das angeforderte Diagnosedatenvolumen beispielsweise prioritätsgesteuert
auf den maximal verfügbaren
Datendurchsatz (Transportkapazität)
begrenzt werden kann.
-
Die
verarbeiteten Applikationsdaten werden anschließend über Ausgabekanäle A (hier
A1, A2, A3) ausgegeben.
-
2 zeigt
ein System (mit um die Funktionalität „Lastmanagement" erweiterter Diagnose-Strategy-Software 3b)
gemäß 1,
wobei auf dem nichtsicheren Rechner 4 mehrere Applikationen 6 (hier
drei Applikationen 6a, 6b, 6c) laufen,
deren angeforderte Eingabedaten die Diagnose-Strategy-Software 3b an
den als Software-Schnittstelle ausgebildeten Tracezugängen T bereitstellt.
-
Weiter
ist ein Applikationsmanager 8 vorgesehen, der über weitere
Steuerschnittstellen mit den Applikationen 6 verbunden
ist.
-
Die
von der Diagnose-Policy-Software 3a bereitgestellten Daten
werden nach der Übertragung in
die Diagnose-Strategy-Software 3b hinsichtlich
ihrer Verwendung als Diagnose- und Applikationsdaten differenziert
und entsprechend weiterverarbeitet. Die Diagnosedaten werden den
Plausibilitätsorakeln
der Diagnose-Strategy-Software 3b zur Bewertung zugeführt und
die Applikationsdaten an den Tracezugängen T im Diagnosesubsystem
des nichtsicheren Rechners 7 für die Applikationen 6 bereitgestellt.
-
Die
für die
Applikationen 6 im nichtsicheren Rechner 4 bereitgestellten
Applikationsdaten können Daten
beliebiger Sensoren S der beiden Kanäle A, B des sicheren Rechners 1 sein.
-
Neben
Sensorrohdaten können
ebenfalls vorverarbeitete Sensordaten, also Prozessdaten, wie beispielsweise
gefilterte und verdichtete Daten übertragen werden. Weiterhin
können
als Inputdaten für den
nichtsicheren Rechner 4 beliebige andere Daten aus der
Verarbeitung im sicheren Rechner 1, wie beispielsweise
Berechnungsergebnisse oder Ausgaben an die Prozessperipherie des
sicheren Rechners 1 verwendet werden. Voraussetzung dafür ist die
Bereitstellung der Daten an den Tracepunkten in der Diagnose-Policy-Software 3a.
-
Die Übertragung
der Applikationsdaten in den nichtsicheren Rechner 4 via
Diagnosesubsystem 3 kann statisch (1) oder
dynamisch (2) organisiert sein.
-
Bei
statischer Übertragung
sind Art und Umfang der Daten je Tracezugang T unveränderlich,
das heißt
das Tracelevel dieser Daten ist konstant. Damit ist die von der
Applikationsdatenübertragung
beanspruchte Datenlast im Diagnosesubsystem 3 als konstante
Grundlast kalkulierbar. Der Lastmanager 7 kann den verbleibenden
Datendurchsatz (die Transportkapazität) für die Systemdiagnose dynamisch aufteilen
und Lastspitzen durch Begrenzen der Diagnosedatenübertragung
abfangen.
-
Bei
dynamischer Übertragung
verändern sich
Umfang oder Häufigkeit
der bereitzustellenden Applikationsdaten an mindestens einem Tracezugang
T. Dieses wird durch Umschaltung des Tracelevels von der Diagnose-Policy-Software 3a anhand von Übertragungsanforderungen
dynamisch gesteuert.
-
Ein
Applikationsmanager 8 als zusätzliche Komponente im nichtsicheren
Rechner 4 sollte immer dann eingeführt werden, wenn im nichtsicheren Rechner 1 mindestens
eine Applikation 6 dynamischen Übertragungsbedarf hat. Der
Applikationsmanager hat neben der Steuerschnittstelle zum Lastmanager 7 auch
Steuerschnittstellen zu allen Applikationen 6 mit dynamischen Übertragungsanforderungen im
nichtsicheren Rechner 4; zu diesen Applikationen 6 gehören hier
alle drei Applikationen 6a, 6b, 6c.
-
Die
Aufgabe des Applikationsmanagers 8 besteht darin, den aktuellen
Datenbedarf (Kommunikationsbedarf) der Applikationen 6 zu
ermitteln und in Steuerkommandos an die Diagnose-Strategy-Software 3b umzusetzen.
Sofern der aktuelle Kommunikationsbedarf der Applikationen 6 eine
vom Lastmager 7 festgelegte Datenmenge überschreitet, reduziert der
Applikationsmanager 8 das angeforderte Datenvolumen entsprechend
nach hinterlegten Regeln, z.B. in Abhängigkeit von Prioritäten, so
dass das zum jeweiligen Zeitpunkt festgelegte Datenvolumen nicht überschritten
wird. Im Ergebnis der Bewertung durch den Applikationsmanager 8 kann
ein Kommunikationsanforderungsprofil generiert werden, welches an
den Lastmanager 7 der Diagnose-Strategy-Software 3b übergeben
wird.
-
Der
Lastmanager 7 bewertet das vom Applikationsmanager angeforderte
Kommunikationsprofil der Applikationen 6 zusammen mit den
aktuell von der Diagnose-Strategy-Software 3b bzw. den
Plausibilitätsorakeln
ermittelten Anforderungen zur Übertragung
von Diagnosedaten. Überschreiten
die Übertragungsanforderungen
in Summe eine festgelegte Lastgrenze, erfolgt eine Reduktion der
Datenmenge durch den Lastmanager 7. Dafür kann der Lastmanager 7 Regeln
und Kriterien verwalten, mit denen in Hochlastsituationen eine Entscheidung
zwischen den konkurrierenden Anforderungen getroffen werden kann.
Im Ergebnis der Bewertung werden durch die Diagnose-Strategy-Software
die Tracelevel an den Diagnoseschnittstellen, also den Tracepunkten, im
sicheren Rechner 1 gesteuert. Die Steuerung der Tracelevel
für die
Applikationsdaten erfolgt dabei indirekt durch die Steuerung der
Tracelevel für
Diagnosedaten.
-
Im
Ergebnis des zweistufigen Lastmanagements durch Applikationsmanager 8 und
Lastmanager 7 können
die Erfordernisse an die Datenbereitstellung für die Applikationen 6 im
nichtsicheren Rechner 4 mit den Anforderungen der Datenübertragung
für die
Systemdiagnose harmonisiert werden. Die Applikationen 6 im
nichtsicheren Rechner 4 können das Diagnosesubsystem 3 als
echtzeitfähige Übertragungsplattform
benutzen, welche alle benötigten
Sensor- und sonstigen Inputdaten (Prozessdaten) vom sicheren Rechner 1 in
den nichtsicheren Rechner 4 spiegeln kann. Darüber hinaus
haben die Applikationen 6 die Möglichkeit, das Kommunikationsverhalten
des Diagnosesubsystems 3 nach ihren Erfordernissen dynamisch
zu steuern. So kann beispielsweise für eine zeitkritische Applikation 6,
deren Inputdaten Lastspitzen aufweisen, ein Prioritätsmechanismus
eingerichtet werden, der dazu führt,
dass in Hochlastsituationen das Diagnosesubsystem 3 die Übertragung
aller anderen Daten zugunsten dieser zeitkritischen Applikation 6 zurückstellt.
-
Ein
wesentliches Kennzeichen der (Kopplungs-)Schnittstelle 5 zwischen
Diagnose-Strategy-Software 3b und Diagnose-Policy-Software 3a besteht
also darin, dass der aus Diagnose- und Applikationsdaten bestehende
Datenstrom dynamisch einerseits an die Notwendigkeit der aktuellen
Prozessverarbeitung und des Systemzustandes angepasst werden kann
und andererseits ein Überlasten der
Schnittstelle 5 mit den ungewollten Folgen wie Datenverlust
oder nichttransparente Übertragungsverzögerung vermieden
wird.
-
Während der
Datentransport an der Diagnoseschnittstelle ausschließlich von
der Diagnose-Policy-Software 3a zur Diagnose-Strategy-Software 3b, also
vom sicheren zum nichtsicheren Rechner 1, 4 erfolgt,
laufen die Steuerkommandos zur Anpassung der Tracelevel ausschließlich in
Richtung Diagnose-Policy-Software 3a.
-
Die
Funktionalität
der (Diagnose)-Schnittstelle 5 bleibt stets gleich.
-
Da
Applikationsdaten, wie beispielsweise Sensordaten, oft auch für Diagnosezwecke
benutzt werden, ist deren mehrfache Verwendung bei nur einmaliger Übertragung
besonders effektiv. Ein großer
Teil der notwendigen Inputdaten für die Applikationen 6 im
nichtsicheren Rechner 4 ist bereits in der Diagnose-Strategy-Software 3b,
also in der Systemdiagnose, ver fügbar,
so dass mit geringem zusätzlichen
Aufwand alle notwendigen Inputdaten in den nichtsicheren Rechner 4 gespiegelt
werden können. Das
Ressourcen schonende und echtzeitfähige Spiegeln der Applikationsdaten
mittels der Diagnoseplattform unterstützt dadurch die Auslagerung
von performanceintensiven Funktionen mit Echtzeitanforderungen aus
dem sicheren Rechner 1.
-
Die
Ergebnisse der Verarbeitung im nichtsicheren Rechner 4 können unmittelbar
für die
Steuerung der Prozessperipherie verwendet werden. Alternativ ist
prinzipiell auch eine Rückübertragung
von Ergebnissen der Verarbeitung vom nichtsicheren Rechner 4 in
den sicheren Rechner 1 möglich. Dieses erfordert allerdings
eine zusätzliche
Schnittstelle, da die bestehende Schnittstelle 5 nur für die Datenübertragung
zum nichtsicheren Rechner 4 ausgelegt ist.
-
Im
Folgenden wird die Anwendung des Verfahrens genauer am Beispiel
des sicheren (Fahrzeug-) Rechners 1 für ein European Train Control System
(kurz ETCS-Zugbeeinflussungssystem) erläutert, der dabei für das Fahrzeug
eine resultierende Höchstgeschwindigkeit
nach streckenseitigen Fahrtvorgaben zu ermitteln und zu überwachen
hat. Bei Überschreiten
der Höchstgeschwindigkeit
ist das Fahrzeug automatisch zu bremsen, so dass Geschwindigkeitsbeschränkungen
des voraus liegenden Streckenabschnitts eingehalten werden.
-
Das
Zugbeeinflussungssystem berechnet und überwacht neben einer auf den
nächsten
Gefahrenpunkt ausgerichteten sicherheitsrelevanten Trajektorie ein
nicht sicherheitsrelevantes betriebliches Geschwindigkeitsprofil,
welches unterhalb der Geschwindigkeit des sicherheitsrelevanten
Profils liegt. Bei Überschreitung
des betrieblichen Geschwindigkeitsprofils wird die Betriebsbremse
betätigt,
während
bei Überschreitung
des sicheren Geschwindigkeitsprofils eine Notbremsung eingeleitet
wird. Die Betriebsbremsung ist also die reguläre Aufgabe der Fahrzeugsteuerung,
während
die Notbremsung eine sicherungs technische Überwachungsfunktion realisiert,
die nur bei Fehlfunktion der regulären Steuerung aktiv wird.
-
Das
Fahrzeug besitzt eine Ortungsfunktion, die auf den Daten mehrerer
unabhängiger
Sensoren, wie beispielsweise Radare und Wegimpulsgeber basiert.
Die Berechnung des aktuellen Fahrzeugorts ist eine Voraussetzung
für die
Ermittlung des zulässigen Geschwindigkeitsverlaufes
aus den streckenseitigen Vorgaben und hat Sicherheitsverantwortung.
Die (Ortungs-) Sensoren S sind an den sicheren (Fahrzeug-) Rechner 1 angeschlossen.
Weiterhin gibt es eine Ansteuerung der Notbremse sowie eine Ansteuerung der
Betriebsbremse durch den sicheren Rechner 1.
-
Die
Neuberechnung des sicheren und nichtsicheren Geschwindigkeitsprofils
und der Bremskurven für
die voraus liegende Strecke ist eine rechenintensive Aufgabe, die
ereignisorientiert im sicheren Rechner 1 anfällt und
zu Performanceproblemen führen
kann. Außerdem
erfolgt zyklisch eine Aktualisierung des sicheren und nichtsicheren
Geschwindigkeitsprofils und der Bremskurven.
-
Der
mit dem sicheren Rechner 1 gekoppelte nichtsichere Rechner 4 ist
aus Verfügbarkeitsgründen redundant
aufgebaut und verschaltet. Der Anschluss der Betriebsbremse wird
vom sicheren Rechner 1 auf den nichtsicheren Rechner 4 verlagert.
-
Im
nichtsicheren Rechner 4 ist neben der Diagnose-Strategy-Software 3b des
Diagnosesubsystems 3 Applikationsfunktionalität implementiert,
die aus dem sicheren Rechner 1 ausgelagert ist und diesen
dadurch entlastet. So übernimmt
der nichtsichere Rechner 1 in diesem Fall beispielhaft
die Berechnung und Ausgabe der nicht sicherheitsrelevanten Betriebsbremsfunktion.
-
Die
vorhandenen (Diagnose-)Schnittstelle 5 im sicheren Rechner 1 wird
genutzt, um Applikationsdaten zur Verfügung zu stellen.
-
Für die Applikationsfunktion
im nichtsicheren Rechner 4 werden die Sensordaten der Ortung
des sicheren Rechners 1 angefordert. Weiterhin benötigt der
nichtsichere Rechner 4 streckenseitige Vorgaben zum Strecken-
und Fahrtverlauf, welche im sicheren Rechner 1 vorliegen
und angefordert werden.
-
Die
Sensordaten der Ortung werden nicht nur als Diagnosedaten im nichtsicheren
Rechner 4 abgelegt, sondern auch von der Applikation 6 im nichtsicheren
Rechner 4 benutzt.
-
Bei
den Sensordaten sind zwei Tracelevel vorgesehen. Im niedrigeren
Tracelevel wird nur jeder fünfte
Sensorinput an die (Diagnose-) Schnittstelle 5 geliefert – für Ortungsanwendungen
ist dieses meistens ausreichend. Im höheren Tracelevel wird jeder Sensorinput
an der Diagnose-Policy-Software 3a ausgekoppelt, so dass
mit höherem Übertragungsaufwand
die kompletten Rohdaten in den nichtsicheren Rechner gespiegelt
werden.
-
Der
Applikation 6 im nichtsicheren Rechner wird je Sensor S
ein Tracezugang T1 im Diagnosesubsystem 3 bereitgestellt.
Zusätzlich
wird ein Tracezugang T2 für
die Bereitstellung streckenseitiger Vorgaben des Strecken- und Fahrtverlauf
bereitgestellt. Die Sensordaten werden zyklisch übertragen, während die
streckenseitigen Fahrtvorgaben ereignisorientiert aktualisiert werden.
-
Die Übertragung
der Sensordaten soll dynamisch in Abhängigkeit vom Betriebsverhalten
und der geforderten Ortungsgenauigkeit des Fahrzeuges erfolgen.
Bei ungebremster Fahrzeugbewegung werden für die Berechnung des Fahrzeugorts
und des Geschwindigkeitsverlaufes Sensordaten mit niedrigem Tracelevel
benutzt. Dieses wird durch den Applikationsmanager 8 ermittelt
und bei der Diagnose-Strategy-Software 3b angefordert.
Die Diagnose-Strategy-Software 3b modifiziert daraufhin
den Tracelevel in der Diagnose-Policy-Software 3a. Die Diagnose- Policy-Software 3a überträgt entsprechend
des gewählten
geringeren Tracelevel die Sensordaten.
-
Während des
Bremsvorganges sollen Sensorrohdaten mit der höchsten Genauigkeit benutzt werden,
um einen Bewegungsablauf auf einen Zielpunkt mit geringer Toleranz
zu erreichen. Der aktuelle Sensordatenbedarf wird von der Applikation 6 über den
Applikationsmanager 8 an die Diagnose-Strategy-Software 3b übermittelt,
welche daraufhin die entsprechenden Tracelevel im sicheren Rechner 1 erhöht. Bei
Bedarf können
beispielsweise auch Daten eines zusätzlichen Ortungssensors während des Bremsvorganges
in den nichtsicheren Rechner 4 übertragen werden, um die Genauigkeit
der Applikation 6 weiter zu verbessern. Nach Abschluss
des Bremsvorganges wird das Tracelevel wieder vermindert.
-
Die Übertragung
der Streckenvorgaben erfolgt statisch. Sobald im sicheren Rechner 1 neue Vorgaben
verfügbar
sind, werden diese über
die Diagnoseschnittstelle am entsprechenden Tracezugang T im nichtsicheren
Rechner 4 aktualisiert, wo die Applikation 6 jeweils über alle
aktuell erforderlichen Daten zur Streckenvorgabe verfügt.
-
Wenn
vom Diagnosesubsystems 3 (Diagnoseorakel) Auffälligkeiten
an einem Ortungssensor S erkannt werden, kann die Erhöhung des
Tracelevel für
diesen Sensor aus Diagnosegründen
ausgelöst werden.
Die Applikation 6 erhält
in diesem Fall mehr Sensordaten als angefordert.
-
Falls
während
einer Betriebsbremsung durch das Diagnosesubsystems 3 fehlerhafte
Systemzustände
erkannt werden, die eine massive zusätzliche Diagnosedatenübertragung
erfordern, welche zusammen mit den Applikationsdaten die Transportkapazität der Kopplungsschnittstelle 5 übersteigen, wird
vom Lastmanager 7 das Datenvolumen prioritätsgesteuert
begrenzt. Die Applikationsdaten werden mit dem höchsten Tracelevel übertragen,
während
für Diagnosedaten
das Tracelevel zeitweise eingeschränkt wird. Dadurch stehen in
diesem Fall zwar weniger Diagnosedaten zur Verfügung, aber die Funktion der
Applikation 6 im nichtsicheren Rechner 4 wird
nicht eingeschränkt.
-
Bei
fehlerhaften Systemzuständen,
die die Funktion der Applikation 6 im nichtsicheren Rechner 4 einschränken, kann
das Verhalten des Lastmanagers 7 anderen Prioritäten unterliegen,
so dass die Gewinnung von Diagnosedaten mit hohem Tracelevel erfolgt,
während
die Applikationsdatenübertragung
mit niedrigem Tracelevel durchgeführt wird.
-
Auf
der Basis der in den nichtsicheren Rechner 4 gespiegelten
Informationen kann die Applikation 6 die performanceintensive
Berechnung des betrieblichen Geschwindigkeitsprofils und die Ansteuerung
der Betriebsbremse in Abhängigkeit
von betrieblichen Anforderungen und des Systemzustandes durchführen und
damit den sicheren Rechner 1 entlasten.