WO2006120165A1

WO2006120165A1 - Zugbeeinflussungssystem

Info

Publication number: WO2006120165A1
Application number: PCT/EP2006/062080
Authority: WO
Inventors: Michael Wenger
Original assignee: Siemens Aktiengesellschaft
Priority date: 2005-05-12
Filing date: 2006-05-05
Publication date: 2006-11-16
Also published as: HK1112653A1; CN100549972C; DE102005023296A1; CN101176070A; DE102005023296B4

Abstract

Die Erfindung betrifft ein Zugbeeinflussungssystem mit mehreren 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. Eine einfache und dennoch sicher Architektur für ein derartiges Zugbeeinflussungssystem ist dadurch gekenn-zeichnet, dass die Fahrzeugrechner (A, B) mit einem Redundanzmanager verbunden sind, der als sicherer Rechner ausge- bildet ist und der die Ausgaben vergleicht und nach Logikkri- terien an die Fahrzeugrechner (A, B) rückbestätigt oder nicht rückbestätigt.

Description

Beschreibung

ZugbeeinflussungsSystem

Die Erfindung betrifft ein Zugbeeinflussungssystem mit den Oberbegriffliehen Merkmalen des Anspruchs 1. Bei bekannten Systemen werden mehrkanalige Rechner, insbesondere vom Typ 2v3, mit mehreren sicheren und redundanten Fahrzeugrechnern eingesetzt. Dabei leisten die synchronisierten Rechnerkanäle die gesamte Datenverarbeitung, wobei jeder Verarbeitungs^¬ schritt 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 Zu- stand „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 ausfallbe^¬ dingt den geschlossenen Zustand der Tür nicht erkennt und der zugehörige Relaiskontakt den Fahrzeugrechner quasi falsch in^¬ formiert, ü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-

Claims

Patentansprüche

1. Zugbeeinflussungssystem mit mehreren nicht redundanten sicheren Fahrzeugrechnern (A, B) , welche unabhängig voneinander sicherungstechnische Ausgaben, z. B. Antrieb frei oder ge^¬ sperrt und Tür frei oder gesperrt, erzeugen, dadurch gekennzeichnet, dass die Fahrzeugrechner (A, B) mit einem Redundanzmanager verbunden sind, der als sicherer Rechner ausgebildet ist und der die Ausgaben vergleicht und nach Logikkriterien an die Fahrzeugrechner (A, B) rückbestätigt oder nicht rückbestä^¬ tigt.

2. Zugbeeinflussungssystem nach Anspruch 1, dadurch gekennzeichnet, dass der Redundanzmanager auf dem Fahrzeug angeordnet ist.

3. Zugbeeinflussungssystem nach Anspruch 1, dadurch gekennzeichnet, dass der Redundanzmanager in einen Streckenrechner integriert ist.

4. Zugbeeinflussungssystem nach Anspruch 1, dadurch gekennzeichnet, dass der Redundanzmanager als Task in den Fahrzeugrechner (A, B) integriert ist.

5. Zugbeeinflussungssystem nach einem der vorangehenden Ansprüche 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

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.

Der Erfindung liegt die Aufgabe zugrunde, eine Systemarchi^¬ tektur zu entwerfen, die einerseits einen sehr hohen Sicherheitsstandard ermöglicht und andererseits ohne synchronisier^¬ te Mehrkanalrechner auskommt.

Die Aufgabe wird mit den kennzeichnenden Merkmalen des Anspruchs 1 gelöst. Der Redundanzmanager sorgt dafür, dass si^¬ cherheitsrelevante Ausgaben nur dann zur Weiterverarbeitung freigegeben werden, wenn diese bei beiden Fahrzeugrechnern übereinstimmen. Der Redundanzmanager ist als sicherer Rechner 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 be- stimmte 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 Fahrzeug^¬ rechner 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 An^¬ triebs angefordert hat und der Freilauf des anderen Fahr^¬ zeugrechners 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 „An^¬ trieb gesperrt" eingestellt sind. - Der Redundanzmanager gibt dem 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 Fahr- zeugrechner 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 Freilaufwertes 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 plau- sible Ortsangaben und übereinstimmende Parameter der Zu- standsmaschinen, 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 Gefahrenpunk^¬ te 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 be^¬ findet 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 Or^¬ tungssystemen 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 Re- dundanzmanager eine generische Plattform für Zugbeeinflus^¬ sungssysteme unterschiedlicher Ausprägung bereit. Diese gene^¬ rische Plattform ist systemspezifisch konfiguriert und lässt sich entsprechend erweitern. Die Systemfunktionalität wird allein von den Fahrzeugrechnern geliefert, die systemspezifi- sehe 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 Redundanzma- nager kann prinzipiell auf beliebige Hardwareplattformen por- tiert werden, ohne dass die Funktion verloren geht.

Gegenüber der Architektur eines sicheren und redundanten Rechnerkerns mit mehreren synchronisierten Rechnerkanälen be- sitzt die Datenverarbeitung über den Redundanzmanager Performancevorteile. Der Grund ist darin zu finden, dass die Daten^¬ verarbeitung, z. B. die zeit- und rechenintensive Ortungs^¬ funktion, 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.

Gemäß Anspruch 2 ist der Redundanzmanager als eigener Rechner auf dem Fahrzeug angeordnet. Die Hardware des redundanten, sicheren Redundanzmanagers kann dabei aus vorhandenen Syste^¬ men, die für Streckenrechner eingesetzt werden, relativ aufwandsarm abgeleitet werden, indem lediglich die Kernbaugrup- pen und die Kommunikationsbaugruppen fahrzeugtauglich ange- passt werden. Das betrifft beispielsweise besondere Ansprüche an Kompaktheit, Umweltbedingungen usw.. Die nichtredundanten, komplexen Spezialbaugruppen des ursprünglichen Streckenrechners zur Ansteuerung der Peripherie können übernommen werden. Systemsoftware ist nicht neu zu entwickeln.

Der Redundanzmanager kann gemäß Anspruch 3 auch in einem Streckenrechner integriert sein. Die Anpassung der Hardware an fahrzeugtaugliche Anforderungen entfällt. Neue Betriebs- Software ist nicht erforderlich. Im Gegensatz zum Fahrzeug^¬ rechner ist der Streckenrechner in bekannten Anwendungen bereits als redundantes System vorhanden. Die Realisierung der Redundanz des Redundanzmanagers ist damit auf den Strecken^¬ rechner konzentriert. Die Kommunikation zwischen Fahrzeug- rechner und Redundanzmanager muss in diesem Fall über Luftspalttelegramme erfolgen.

Der Redundanzmanager kann aber gemäß Anspruch 4 auch als Task in den Fahrzeugrechnern integriert sein. In diesem Fall ist nur ein Minimum an Hardware erforderlich. 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. In dieser Architek- turvariante ist 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.

Gemäß Anspruch 5 erteilt der Redundanzmanager einem Fahrzeugrechner auch Sonderaufträge, genehmigt Anträge der Fahrzeug^¬ rechner und lädt Daten von einem Fahrzeugrechner in den ande- ren. 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. Der Fahrzeugrechner ist auch in nicht redundanten Systemen einsetzbar, wobei dann die Software derart beschaffen sein muss, dass die Zustimmungspflicht bestimmter Aktionen projek^¬ tiert werden kann. Das ist auch dann der Fall, wenn der Re- dundanzmanager ohnehin als Task auf den einzelnen Fahrzeugrechnern läuft - Anspruch 4. Das nicht redundante System arbeitet dann wie ein redundantes System, bei dem ein Fahrzeug^¬ rechner ausgefallen ist.

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 System Zug/Strecke, bei dem das Teilsys^¬ tem Zug zwei sicherungstechnische Ausgaben, nämlich Türmotor frei oder gesperrt und Fahrzeugantrieb frei oder gesperrt, aufweist, wobei jeder Ausgabe eine Zustandsmaschine zur Er- zeugung der notwendigen Eingangsinformationen zugeordnet ist. Die Zustandsmaschinen beaufschlagen zwei unabhängige sichere Fahrzeugrechner A und B. Dieses System kann anwendungsspezifisch erweitert werden. Beide Fahrzeugrechner A und B sind über Luftschnittstellen mit einem Redundanzmanager verbunden, der als Softwaremodul im Streckenrechner vorgesehen ist. Der Redundanzmanager kann aber auch als eigener Rechner auf dem Fahrzeug oder als Task in beiden Fahrzeugrechnern A und B angesiedelt sein. Im letzteren Fall ist im störungsfreien Zustand der Redundanzmanager eines Fahrzeugrechners A oder B Master und der andere Slave. Prinzipiell muss gewährleistet sein, dass betrieblich eine kontinuierliche Kommunikations- verbindung 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ür^¬ motors 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 Fahr^¬ zeugrechner A und B den jeweiligen Kontakt offen steuern. Jeder Fahrzeugrechner A und B ist über eine eigene bidirektio^¬ nale Kommunikationsverbindung mit dem Redundanzmanager ver- bunden. 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 Kommunikationsver- bindung 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 zuge^¬ ordnete Ausgabe sofort gesperrt werden, d. h. der entspre^¬ chende Kontakt öffnet. Dieser Zustand wird dem Redundanzmana- ger 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 Zustandsmaschi- nen plausibel zu den geladenen Werten sind und er den Freilauf wieder erteilt bekommen hat.

Die Erfindung beschränkt sich nicht auf das vorstehend ange^¬ gebene 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 .