Beschreibung

Verfahren zur Steuerung und überwachung eines sich entlang einer Fahrstrecke bewegenden Fahrzeugs, insbesondere zur sig- naltechnisch sicheren Zugbeeinflussung

Die Erfindung betrifft ein Verfahren zur Steuerung und überwachung eines sich entlang einer Fahrstrecke bewegenden Fahrzeugs, insbesondere zur signaltechnisch sicheren Zugbeein- flussung 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 si ^¬ chere Rechner beispielsweise eine Notbremsung des Fahrzeugs ein .

Sichere Rechner sind als Mehrrechnersysteme ausgelegt, wobei mittels spezieller Maßnahmen, beispielsweise einer mehrkana- ligen 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 Hardwareauf- wand 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 die ^¬ sem 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. Wei ^¬ ter 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-) Schnitt ^¬ stelle 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 Entlas- tung 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 angefor- dert und von dieser über die (Diagnose-) Schnittstelle bereit ^¬ gestellt werden. Zweckmäßigerweise ist im sicheren Rechner mindestens ein Beobachtungspunkt/Tracepunkt vorgesehen, an dem die Diagnose-Policy-Software die angeforderten Sensorda ^¬ ten/Prozessdaten auskoppelt.

Zur stärkeren Entlastung des sicheren Rechners wird vorgeschlagen, dass die Diagnose-Strategy-Software die Sensorda ^¬ ten/Prozessdaten für mehrere Applikationen an als Software- Schnittstelle ausgebildeten Tracezugängen der Diagnose-Stra- tegy-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-

wäre 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 si- cheren Rechners stellt der Lastmanager die Funktionen und Regeln zur überwachung und Begrenzung des aus Sensordaten/Prozessdaten bestehenden Datenübertragungsvolumens be ^¬ reit, 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:

Figur 1 ein System zur Zugbeeinflussung mit einem sicheren und einem mit diesem verbundenen nichtsicheren

Rechner, und

Figur 2 ein System gemäß Figur 1 erweitert durch einen Applikationsmanager .

Figur 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 signal- technisch sicheren Rechner 1 auf, der mit mehreren außerhalb des Rechners 1 angeordneten Sensoren S (hier Sl, S2, S3, S4) verbunden ist, welche Fahrzeugdaten erfassen und als Sensordaten an den Eingängen E (El, E2, E3, E4) des sicheren Rechners 1 diesem zur weiteren Verarbeitung zur Verfügung stel- len.

Der sichere Rechner 1 ist zweikanalig mit den beiden identi ^¬ schen 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 Anwen ^¬ dungsprogrammen 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 (Beobach ^¬ tungspunkte) des sicheren Rechners 1 hat, zu denen die Ein ^¬ gänge E gehören und an welchen die Diagnose-Policy-Software

3aZugang 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-Stra- tegy-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 voll- ständiges Diagnosesubsystem 3 bildet, wobei die als Plausibi- litätsorakel arbeitende Diagnose-Strategy-Software 3b anhand der angeforderten Diagnosedaten eine Systemdiagnose abgibt. Von Orakel kann man hier deshalb sprechen, weil zur Systembe ^¬ obachtung immer nur ein kleiner Teil der Prozessdaten des si- cheren 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 diagnos- tizieren 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 si ^¬ cheren Rechners 1 für signaltechnisch nichtsichere Zwecke verarbeitet, an die geringe bis keine Sicherheitsanforderun ^¬ gen gestellt werden. Bei Bedarf können beliebig viele Applikationen 6 im nichtsicheren Rechner 4 implementiert werden.

Die von der Applikation 6 benötigten Applikationsdaten (ins- besondere Sensordaten) werden unter Ausnutzung des vorhandenen Diagnosesubsystems 3 wie die Diagnosedaten über die Diag- nose-Strategy-Software 3b bei der Diagnose-Policy-Software 3a angefordert und über Tracezugänge T (hier Tl, T2, T3, T4), die als Software-Schnittstellen ausgebildet sind, der Appli- kation 6 von der Diagnose-Strategy-Software 3b bereitge ^¬ stellt.

Ein Lastmanager 7, hier im Ausführungsbeispiel die um eine Funktionalität zum Lastmanagement erweiterte Diagnose-Stra- tegy-Software 3b wie in Figur 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 Gesamt- datenvolumen, 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 Al, A2, A3) ausgegeben.

Figur 2 zeigt ein System (mit um die Funktionalität „Lastma ^¬ nagement" erweiterter Diagnose-Strategy-Software 3b) gemäß Figur 1, wobei auf dem nichtsicheren Rechner 4 mehrere Appli- kationen 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 Da- ten 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 be- reitgestellten 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 In- putdaten für den nichtsicheren Rechner 4 beliebige andere Daten aus der Verarbeitung im sicheren Rechner 1, wie beispielsweise Berechnungsergebnisse oder Ausgaben an die Pro- zessperipherie des sicheren Rechners 1 verwendet werden. Vor ^¬ aussetzung dafür ist die Bereitstellung der Daten an den Tra- cepunkten in der Diagnose-Policy-Software 3a.

Die übertragung der Applikationsdaten in den nichtsicheren Rechner 4 via Diagnosesubsystem 3 kann statisch (Figur 1) oder dynamisch (Figur 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 Be- grenzen 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 die- sen Applikationen 6 gehören hier alle drei Applikationen 6a, 6b, 6c.

Die Aufgabe des Applikationsmanagers 8 besteht darin, den ak ^¬ tuellen Datenbedarf (Kommunikationsbedarf) der Applikationen 6 zu ermitteln und in Steuerkommandos an die Diagnose-Stra- tegy-Software 3b umzusetzen. Sofern der aktuelle Kommunika- tionsbedarf der Applikationen 6 eine vom Lastmager 7 festgelegte Datenmenge überschreitet, reduziert der Applikationsma ^¬ nager 8 das angeforderte Datenvolumen entsprechend nach hin ^¬ terlegten 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 über- tragung 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-Soft ^¬ ware die Tracelevel an den Diagnoseschnittstellen, also den Tracepunkten, im sicheren Rechner 1 gesteuert. Die Steuerung der Tracelevel für die Applikationsdaten erfolgt dabei indi- rekt durch die Steuerung der Tracelevel für Diagnosedaten.

Im Ergebnis des zweistufigen Lastmanagements durch Applika ^¬ tionsmanager 8 und Lastmanager 7 können die Erfordernisse an die Datenbereitstellung für die Applikationen 6 im nichtsi- cheren 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 Diagnosesubsys- tems 3 nach ihren Erfordernissen dynamisch zu steuern. So kann beispielsweise für eine zeitkritische Applikation 6, de ^¬ ren Inputdaten Lastspitzen aufweisen, ein Prioritätsmechanismus eingerichtet werden, der dazu führt, dass in Hochlastsi ^¬ tuationen das Diagnosesubsystem 3 die übertragung aller ande- ren 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öge ^¬ rung vermieden wird.

Während der Datentransport an der Diagnoseschnittstelle aus ^¬ schließ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 Anpas ^¬ sung 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 be- stehende 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 brem- sen, so dass Geschwindigkeitsbeschränkungen des voraus liegenden Streckenabschnitts eingehalten werden.

Das Zugbeeinflussungssystem berechnet und überwacht neben einer auf den nächsten Gefahrenpunkt ausgerichteten sicher- heitsrelevanten 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 überwachungs funktion 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äs ^¬ sigen Geschwindigkeitsverlaufes aus den streckenseitigen Vor ^¬ gaben und hat Sicherheitsverantwortung. Die (Ortungs-) Senso- ren S sind an den sicheren (Fahrzeug-) Rechner 1 angeschlos ^¬ sen. 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 ereignisorien ^¬ tiert im sicheren Rechner 1 anfällt und zu Performanceproble ^¬ men führen kann. Außerdem erfolgt zyklisch eine Aktualisie- rung 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 siche ^¬ ren Rechner 1 auf den nichtsicheren Rechner 4 verlagert.

Im nichtsicheren Rechner 4 ist neben der Diagnose-Strategy- Software 3b des Diagnosesubsystems 3 Applikationsfunktionali- tat implementiert, die aus dem sicheren Rechner 1 ausgelagert ist und diesen dadurch entlastet. So übernimmt der nichtsi ^¬ chere Rechner 1 in diesem Fall beispielhaft die Berechnung und Ausgabe der nicht sicherheitsrelevanten Betriebsbrems ^¬ funktion .

Die vorhandenen (Diagnose-) Schnittstelle 5 im sicheren Rech ^¬ ner 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, wel ^¬ che 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 Ap- plikation 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 Ortungsanwendun- gen ist dieses meistens ausreichend. Im höheren Tracelevel wird jeder Sensorinput an der Diagnose-Policy-Software 3aausgekoppelt, 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 Tl im Diagnosesubsystem 3 bereitgestellt. Zusätzlich wird ein Tracezugang T2 für die Bereitstellung stre- ckenseitiger Vorgaben des Strecken- und Fahrtverlauf bereit- gestellt. Die Sensordaten werden zyklisch übertragen, während die streckenseitigen Fahrtvorgaben ereignisorientiert aktualisiert werden.

Die übertragung der Sensordaten soll dynamisch in Abhängig- keit vom Betriebsverhalten und der geforderten Ortungsgenauigkeit des Fahrzeuges erfolgen. Bei ungebremster Fahrzeugbe ^¬ wegung werden für die Berechnung des Fahrzeugorts und des Ge ^¬ schwindigkeitsverlaufes Sensordaten mit niedrigem Tracelevel benutzt. Dieses wird durch den Applikationsmanager 8 ermit- telt 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 ge ^¬ ringeren 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 Tracele- vel im sicheren Rechner 1 erhöht. Bei Bedarf können beispielsweise auch Daten eines zusätzlichen Ortungssensors wäh ^¬ rend des Bremsvorganges in den nichtsicheren Rechner 4 übertragen werden, um die Genauigkeit der Applikation 6 weiter zu verbessern. Nach Abschluss des Bremsvorganges wird das Trace- level 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 Trace- zugang 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älligkei- ten 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 Diagnosesub ^¬ systems 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 Lastmana- ger 7 das Datenvolumen prioritätsgesteuert begrenzt. Die Ap ^¬ plikationsdaten werden mit dem höchsten Tracelevel übertragen, während für Diagnosedaten das Tracelevel zeitweise ein ^¬ geschrä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 Appli- kation 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 betriebli- chen Anforderungen und des Systemzustandes durchführen und damit den sicheren Rechner 1 entlasten.