DE102005023296B4

DE102005023296B4 - Zugbeeinflussungssystem

Info

Publication number: DE102005023296B4
Application number: DE200510023296
Authority: DE
Inventors: Michael Wenger
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2005-05-12
Filing date: 2005-05-12
Publication date: 2007-07-12
Anticipated expiration: 2025-05-13
Also published as: WO2006120165A1; DE102005023296A1; CN100549972C; CN101176070A; HK1112653A1

Abstract

Zugbeeinflussungssystem mit zwei nicht redundanten sicheren Fahrzeugrechnern (A, B), welche unabhängig voneinander sicherungstechnische Ausgaben, z. B. Antrieb frei oder gesperrt und Tür frei oder gesperrt, erzeugen, dadurch gekennzeichnet, dass in den Fahrzeugrechnern (A, B), die keine Kenntnis voneinander oder Verbindung zueinander haben, jeweils ein als Task ausgebildeter Redundanzmanager integriert ist, der die Ausgaben vergleicht und nach Logikkriterien an die Fahrzeugrechner (A, B) rückbestätigt oder nicht rückbestätigt, wobei ein Task als Master und der andere Task als Slave fungiert.

Description

Die Erfindung betrifft ein Zugbeeinflussungssystem mit den oberbegrifflichen Merkmalen des Anspruchs 1. Bei bekannten Systemen werden mehrkanalige Rechner, insbesondere vom Typ 2v3, wie beispielsweise aus der DE 23 03 828 A bekannt, mit mehreren sicheren und redundanten Fahrzeugrechnern eingesetzt. Dabei leisten die synchronisierten Rechnerkanäle die gesamte Datenverarbeitung, wobei jeder Verarbeitungsschritt nach dem Zeitscheibenverfahren gevotet wird. Derartige Mehrkanalsysteme mit quasi ständigem Voting genügen zwar hohen Sicherheitsanforderungen, sind aber aufwendig sowohl hinsichtlich Hardware als auch hinsichtlich Software.

Vorstellbar ist auch die Verwendung eines einfacheren Systems, bei dem zwei sichere, nicht redundante Fahrzeugrechner zur Erzeugung sicherungstechnischer Ausgaben verwendet werden. Prinzipiell kann immer angenommen werden, dass im Zustand „Fahrt" der Antrieb sicherungstechnisch freigegeben und der Türmotor sicherungstechnisch gesperrt sein müssen. Im Zustand „Abfertigung" muss hingegen der Antrieb sicherungstechnisch gesperrt sein, während der Türmotor betrieblich freigegeben ist. Bei diesen Voraussetzungen können bei Verwendung separater sicheren Fahrzeugrechner Probleme auftreten, die nachfolgend anhand eines Beispiels erläutert werden. Befindet sich beispielsweise ein Fahrzeugrechner noch im Betriebszustand „Abfertigung", weil eine Zustandsmaschine ausfallbedingt den geschlossenen Zustand der Tür nicht erkennt und der zugehörige Relaiskontakt den Fahrzeugrechner quasi falsch informiert, überwacht dieser den Stillstand des Zuges und gibt die Türen frei. Befindet sich der andere Rechner bereits im Zustand „Fahrt", weil seine Zustandsmaschine störungsfrei ist und die Türen als geschlossen gemeldet hat, gibt dieser zwei te Fahrzeugrechner die Fahrt frei und sperrt die Türen. Die Überlagerung beider Ausgaben ergibt einen gefährlichen Zustand, nämlich die gleichzeitige Freigabe zur Fahrt und zur Öffnung der Türen.

Aus der DD 229 878 A1 ist ein Zugbeeinflussungssystem mit Mehrrechner-Fahrzeugrechnern bekannt, welche mit Streckenrechnern über Funk Datentelegramme austauschen.

Aus der DE 195 01 993 A1 ist es bekannt, per Funk abgefragte Zustände von Streckensicherungseinrichtungen auf einem Bordcomputer mit Referenzzuständen zu vergleichen.

Die DE 699 05 272 T2 offenbart ein Verfahren zum Umgang mit Datenverarbeitungsfehlern, die temporärer Natur sind.

Der Erfindung liegt die Aufgabe zugrunde, eine Systemarchitektur zu entwerfen, die einerseits einen sehr hohen Sicherheitsstandard ermöglicht und andererseits ohne synchronisierte Mehrkanalrechner auskommt.

Die Aufgabe wird mit den kennzeichnenden Merkmalen des Anspruchs 1 gelöst. Der Redundanzmanager, d. h. der Master-Task oder ersatzweise der Slave-Task, sorgt dafür, dass sicherheitsrelevante Ausgaben nur dann zur Weiterverarbeitung freigegeben werden, wenn diese bei beiden Fahrzeugrechnern übereinstimmen. Der Redundanzmanager ist als Task in beiden sicheren Fahrzeugrechnern ausgebildet, weil sein Fehlverhalten zu – im Beispiel oben erläuterten – unterschiedlichen Betriebszuständen beider Fahrzeugrechner oder zum Laden falscher Daten von einem Fahrzeugrechner in den anderen führen könnte. Dabei werden bestimmte Logikkriterien vom Redundanzmanager berücksichtigt. Folgende Algorithmen können beispielsweise implementiert sein:

– Der Redundanzmanager gibt den Antrieb für beide Fahrzeugrechner nur frei, wenn beide Fahrzeugrechner zuvor den Türmotor als gesperrt gemeldet haben und beide Fahrzeugrechner die Freigabe für den Fahrzeugantrieb angefordert haben.
– Der Redundanzmanager gibt den Antrieb für einen Fahrzeugrechner nur frei, wenn dieser Fahrzeugrechner zuvor den Türmotor als gesperrt gemeldet und die Freigabe des Antriebs angefordert hat und der Freilauf des anderen Fahrzeugrechners mit Sicherheit abgelaufen ist, wobei der Freilauf eine einstellbare Zeit oder Strecke charakteri siert, für die keine Verbindung zwischen dem Fahrzeugrechner und dem Redundanzmanager besteht, wobei im Freilauf immer die sicheren Zustände „Tür gesperrt" und „Antrieb gesperrt" eingestellt sind.
– Der Redundanzmanager gibt den Türmotor für beide Fahrzeugrechner nur frei, wenn beide Fahrzeugrechner zuvor den Antrieb als gesperrt gemeldet und auch beide die Freigabe des Türmotors angefordert haben.
– Der Redundanzmanager gibt dem Türmotor für einen Fahrzeugrechner nur frei, wenn dieser Fahrzeugrechner zuvor den Antrieb als gesperrt gemeldet und die Freigabe des Türmotors angefordert hat und der Freilauf des anderen Fahrzeugrechners mit Sicherheit abgelaufen ist.
– Erreicht der Zustand „Freigabeanforderung" des zweiten Fahrzeugrechners den ersten Fahrzeugrechner nach einer festzulegenden Zeit oder einer zurückgelegten Wegstrecke nicht, entzieht der Redundanzmanager dem ersten Rechner den Freilauf. Nach Ablauf des Freilauf wertes oder nach Quittierung des Entzugs durch diesen ersten Rechner kommt der Redundanzmanager den Freigabeanforderungen des zweiten Rechners nach.
– Einem ersten Fahrzeugrechner, dessen Freilauf abgelaufen ist, wird der Freilauf wieder erteilt, wenn er richtige Zustände meldet, beispielsweise zum anderen Rechner plausible Ortsangaben und übereinstimmende Parameter der Zustandsmaschinen, die den Fahrzeugrechnern die Eingangsdaten liefern, und das System einen stabilen Zustand angenommen hat. Systemspezifisch festzulegende Zustände des zweiten Rechners werden in den ersten Rechner geladen. Das betrifft beispielsweise zu überwachende Gefahrenpunkte mit Höchstgeschwindigkeiten sowie Betriebszustände des zweiten Rechners wie „Abfertigung" oder „Fahrt".

Diese Algorithmen und Logikkriterien können systemspezifisch durch weitere ergänzt werden. Sinnvoll kann z. B. sein, dass ein Fahrauftrag einem Fahrzeugrechner vom Redundanzmanager erst freigegeben wird, wenn dieser Fahrzeugrechner sich im gleichen Betriebszustand wie der zweite Fahrzeugrechner befindet oder wenn für diesen der Freilauf überschritten wurde. Diese Regel kann z. B. die häufig unterschiedlichen Zeitpunkte des Überfahrens eines Ortungspunktes, die von beiden Ortungssystemen der Fahrzeugrechner parallel ermittelt werden, ausgleichen.

Der Redundanzmanager dient lediglich dazu, die erforderlichen Logikkriterien zu realisieren. Er besitzt keine eigentlichen systemspezifischen Funktionen. In diesem Sinne stellt der Redundanzmanager eine generische Plattform für Zugbeeinflussungssysteme unterschiedlicher Ausprägung bereit. Diese generische Plattform ist systemspezifisch konfiguriert und lässt sich entsprechend erweitern. Die Systemfunktionalität wird allein von den Fahrzeugrechnern geliefert, die systemspezifische Dienste zur Verfügung stellen, die der Redundanzmanager voted und nach Logikkriterien beurteilt.

Die Architektur des Zugbeeinflussungssystems ist weitgehend unabhängig von der Hardware. Das System mit dem Redundanzmanager kann prinzipiell auf beliebige Hardwareplattformen portiert werden, ohne dass die Funktion verloren geht.

Gegenüber der Architektur eines sicheren und redundanten Rechnerkerns mit mehreren synchronisierten Rechnerkanälen besitzt die Datenverarbeitung über den Redundanzmanager Performancevorteile. Der Grund ist darin zu finden, dass die Datenverarbeitung, z. B. die zeit- und rechenintensive Ortungsfunktion, parallel von den Fahrzeugrechnern erfolgt. Der Redundanzmanager voted anschließend nur die Ergebnisse, während bei mehrkanaliger Datenverarbeitung mit synchronisierten Rechnern ein quasi ständiges Voting nach dem Zeitscheibenverfahren erforderlich ist.

Der Redundanzmanager ist als Task in den Fahrzeugrechnern integriert, wodurch nur ein Minimum an Hardware erforderlich ist. Nur der erste der beiden Redundanzmanager würde im störungsfreien Zustand das Management übernehmen und als Master fungieren, während der zweite Redundanzmanager im anderen Fahrzeugrechner sein Slave wäre. Der zweite Redundanzmanager muss nur ständig mitlaufen, um auf den aktuellen Stand der Betriebszustände zu sein. Ein Ausfall des ersten Fahrzeugrechners hat zur Folge, dass auch der als Task vorgesehene Master-Redundanzmanager ausfallen würde. In diesem Fall übernimmt der zweite Redundanzmanager den Betrieb. Der zweite Redundanzmanager vergibt dann alle vorhandenen Aufträge an den zweiten Fahrzeugrechner, welcher diese Anforderungen positiv bestätigen muss. Eine Kommunikationsverbindung des Slave-Redundanzmanagers zum ersten Fahrzeugrechner ist nicht zwingend notwendig. Es ist lediglich genau festzulegen, durch welche Reaktionen der Ausfall des Master-Redundanzmanagers den noch intakten Rechnern mitzuteilen ist. Denkbar ist z. B. eine sichere Ausgabe vom ersten Fahrzeugrechner, der den Zustand des Master-Redundanzrechners wiedergibt und von beiden Fahrzeugrechnern abgefragt wird.

Der Fahrzeugrechner ist auch in nicht redundanten Systemen einsetzbar, wobei dann die Software derart beschaffen sein muss, dass die Zustimmungspflicht bestimmter Aktionen projektiert werden kann. Das ist der Fall, da der Redundanzmanager ohnehin als Task auf den einzelnen Fahrzeugrechnern läuft. Das nicht redundante System arbeitet dann wie ein redundantes System, bei dem ein Fahrzeugrechner ausgefallen ist.

Gemäß Anspruch 2 erteilt der Redundanzmanager einem Fahrzeugrechner auch Sonderaufträge, genehmigt Anträge der Fahrzeugrechner und lädt Daten von einem Fahrzeugrechner in den anderen. Neben der Verarbeitung der von den Zustandsmaschinen stammenden Eingangsdaten können systemspezifisch noch weitere Aktionen der Fahrzeugrechner notwendig sein, die der Genehmigungspflicht durch den Redundanzmanager unterliegen bzw. die vom Redundanzmanager beauftragt werden. Beispiele hierfür sind die Zugdateneingabe bei ETCS (European Train Control System), eine Mode-Umschaltung oder ein Zugbus-Kommando zur Abschaltung des Antriebs. Jeder Fahrzeugrechner kann von dem Redundanzmanager mit der Ausübung bestimmter Funktionen beauftragt werden. Das kann beispielsweise die nicht rückbestätigungspflichtige Ansteuerung einer Fahrplankonformitätsanzeige betreffen. Die Beauftragung erlischt automatisch, wenn dem Fahrzeugrechner der Freilauf entzogen wird.

Die Erfindung wird nachfolgend anhand einer figürlichen Darstellung näher erläutert.

Die einzige Figur zeigt eine Systemarchitektur für ein Zugbeeinflussungssystem.
Dargestellt ist ein Zugbeeinflussungssystem, das zwei sicherungstechnische Ausgaben, nämlich Türmotor frei oder gesperrt und Fahrzeugantrieb frei oder gesperrt, aufweist, wobei jeder Ausgabe eine Zustandsmaschine zur Erzeugung der notwendigen Eingangsinformationen zugeordnet ist. Die Zustandsmaschinen beaufschlagen zwei unabhängige sichere Fahrzeugrechner A und B. Dieses System kann anwendungsspezifisch erweitert werden. In beiden Fahrzeugrechnern A und B ist ein Redundanzmanager als Task angesiedelt. Zur Veranschaulichung der Tasks ist der Redundanzmanager als Softwaremodul dargestellt Im störungsfreien Zustand ist der Redundanzmanager eines Fahrzeugrechners A oder B Master und der andere Slave. Prinzipiell muss gewährleistet sein, dass betrieblich eine kontinuierliche Kommunikationsverbindung zwischen den Fahrzeugrechnern A und B und dem Redundanzmanager realisiert werden kann. Die beiden Fahrzeugrechner A und B im Zug haben keine Kenntnis voneinander oder Verbindung zueinander. Jeder Rechner A und B besitzt in dem Beispiel zwei Ausgaben, nämlich Stellenergiefreigabe des Türmotors und des Antriebs. Steuert im ausfallfreien Zustand auch nur ein Fahrzeugrechner A oder B einen Kontakt in den Zustand „geschlossen", wird die Stellenergie freigegeben. Eine Sperrung der Stellenergie erfolgt nur, wenn beide Fahrzeugrechner A und B den jeweiligen Kontakt offen steuern. Jeder Fahrzeugrechner A und B ist über eine eigene bidirektionale Kommunikationsverbindung mit dem Redundanzmanager verbunden. Die Zustandsmaschinen erzeugen nicht sicher die Zustände „Tür frei" und „Antrieb frei". Beim Wechsel in diesen Zustand ist die zugeordnete Ausgabe, d. h. „Kontakt schließen", vorgewählt. Bevor die Ausgabe erfolgt, ist jedoch die Zustimmung des Redundanzmanagers über die Kommunikationsverbindung notwendig. Die Zustände „Tür gesperrt" und „Antrieb gesperrt" werden durch die Zustandsmaschinen nicht sicher erzeugt. Beim Wechsel in diesen Zustand muss folglich die zugeordnete Ausgabe sofort gesperrt werden, d. h. der entsprechende Kontakt öffnet. Dieser Zustand wird dem Redundanzmanager gemeldet.
Sobald ein Fahrzeugrechner A bzw. B für eine einstellbare Zeit oder für eine vorwählbare Strecke keine Verbindung mehr zum Redundanzmanager besitzt, d. h. im Zustand des Freilaufs, stellt dieser Fahrzeugrechner A bzw. B beide Kontakte in den Zustand offen. Die Ortsermittlung wird durch diesen Rechner A oder B weiterhin durchgeführt. Der Freilauf bleibt bestehen, wenn der Fahrzeugrechner A oder B vom Redundanzmanager mit aktuellen Zuständen geladen worden ist, seine Zustandsmaschinen plausibel zu den geladenen Werten sind und er den Freilauf wieder erteilt bekommen hat.
Die Erfindung beschränkt sich nicht auf das vorstehend angegebene Ausführungsbeispiel. Vielmehr ist eine Anzahl von Va rianten denkbar, welche auch bei grundsätzlich anders gearteter Ausführung von den Merkmalen der Erfindung Gebrauch machen.

Claims

Zugbeeinflussungssystem mit zwei nicht redundanten sicheren Fahrzeugrechnern (A, B), welche unabhängig voneinander sicherungstechnische Ausgaben, z. B. Antrieb frei oder gesperrt und Tür frei oder gesperrt, erzeugen, dadurch gekennzeichnet, dass in den Fahrzeugrechnern (A, B), die keine Kenntnis voneinander oder Verbindung zueinander haben, jeweils ein als Task ausgebildeter Redundanzmanager integriert ist, der die Ausgaben vergleicht und nach Logikkriterien an die Fahrzeugrechner (A, B) rückbestätigt oder nicht rückbestätigt, wobei ein Task als Master und der andere Task als Slave fungiert.
Zugbeeinflussungssystem nach Anspruch 1, dadurch gekennzeichnet, dass der Redundanzmanager den Fahrzeugrechnern (A, B) nicht rückbestätigungspflichtige Aufträge, z. B. Ansteuerung einer Fahrplankonformitätsanzeige, erteilt und/oder Anträge der Fahrzeugrechner (A, B) genehmigt und/oder Daten von einem Fahrzeugrechner (A, B) in andere Fahrzeugrechner (B, A) lädt.