-
Die
Erfindung betrifft ein Verfahren zum datenbankgestützten,
sicheren Steuern von Elementen der Leit- und Sicherungstechnik mit
kabelloser Datenübertragung über große
Stellentfernungen hinweg.
-
Der
Fahrbetrieb von Schienenfahrzeugen wird bei technisch gesicherten
Strecken zentral von einem für den entsprechenden Infrastrukturbereich
zuständigen Stellwerk geleitet und gesichert.
-
Die
Elemente der Außenanlage des Stellwerks, wie z. B. Signale,
Weichen, Bahnübergänge, Blockeinrichtungen etc.
müssen von der Stellwerkslogik dabei signaltechnisch sicher
gesteuert und überwacht werden.
-
Hierfür
müssen die Elemente der Außenanlage ihre Befehle
zuverlässig und sicher vom Stellwerk erhalten.
-
Genauso
zuverlässig und sicher muss gewährleistet sein,
dass im Stellwerk zutreffende Informationen über den Zustand
der Elemente der Außenanlage vorliegen.
-
Die
Kommunikation zwischen den Elementen der Außenanlage und
dem Stellwerk muss also gewährleisten, dass die Informationen,
die ausgetauscht werden, unverfälscht übermittelt
werden.
-
Um
diese Sicherheit zu erreichen, hat man bisher im Netz der DB AG
Telekommunikationskabel eingesetzt. Die aufwändige Verkabelung
bringt die Nachteile hoher Installationskosten sowie die räumliche
Beschränkung der Stellbezirke auf Stellentfernungen von
circa 15 km mit sich.
-
Aus
DE 41 07 639 A1 ist
eine Einrichtung zur signaltechnisch sicheren Fernsteuerung einer
Unterstation einer Eisenbahnanlage bekannt. Hierbei wird über
Kabel ein Stellbefehl, der eine Stellhandlung mit Sicherheitsverantwortung
auslöst, zunächst ohne signaltechnische Sicherheit
in die Unterstation übertragen. Danach wird die Stellhandlung,
bevor sie ausgeführt wird, über den signaltechnisch
sicher ausgelegten Meldeweg in die zentrale Station zurück
gespiegelt. Nach nochmaliger Kontrolle des Stellbefehls wird ein
signaltechnisch sicher wirkendes Ausführungskommando an
die Unterstation übertragen. Als Ausführungskommando
wird ein in der Unterstation erzeugter, dort gespeicherter Sicherungscode
verwendet. Dieser wird zusammen mit der zu spiegelnden Stell handlung
an die Zentralstation übermittelt. Als Ausführungskommando
wird er in der Zentralstation erneut eingegeben, nicht sicher zur
Unterstation übertragen und dort mit dem ursprünglichen
Sicherungscode verglichen. Bei Übereinstimmung wird die
Stellhandlung ausgeführt.
-
Dieses
Verfahren ist jedoch an die Verwendung von Datenübertragungskabeln
gebunden, so dass die Stellentfernung auf etwa 10 bis 15 km beschränkt
ist.
-
Aus
DE 10 2004 062 987
A1 ist ein Verfahren zur Realisierung eines virtuellen
Streckenblocks unter Nutzung funkgesteuerter Fahrwegelemente bekannt,
bei der die steuerbaren Fahrwegelemente über Funk angesteuert
werden.
-
Das
Verfahren ist allerdings nicht dazu geeignet, alle erforderlichen
Stellbefehle von elektronischen Stellwerken sowie die Rückmeldungen
der Elementansteuermodule, die für den Eisenbahnbetrieb
auf Hauptstrecken erforderlich sind, zu verarbeiten.
-
Aus
EP 1 420 566 A1 ist
ein Verfahren und eine Vorrichtung zum Datenaustausch zwischen mobilen Endgeräten
und zentralen Diensten unter Verwendung eines Kommunikationsservers,
der die Anfragen der mobilen Endgeräte an die zentralen
Dienste umsetzt, bekannt. Dieses Verfahren beschränkt sich
auf den Austausch von Daten mittels Verwendung von Datenarrays zwischen
Client und Server. Das Verfahren ist allerdings nicht dazu geeignet,
alle erforderlichen Stellbefehle von elektronischen Stellwerken
sowie die Rückmeldungen der Elementansteuermodule, die
für den Eisenbahnbetrieb auf Hauptstrecken erforderlich
sind, auch bei Systemausfall, programmgemäß sicher
zu verarbeiten (hin- und rückzumelden).
-
Der
Erfindung liegt die Aufgabe zugrunde, ein Verfahren für
eine kabellose Datenübertragung zur Ansteuerung von Elementen
der Leit- und Sicherungstechnik über große Stellentfernungen
(ca. 50 km) hinweg zu realisieren und die Anzahl von Steuerungsanlagen
der Leit- und Sicherungstechnik (Kabelwege und gegebenenfalls Elementansteuermodule,
EAM) zu reduzieren, wobei die Durchführung der Stellbefehle
und -rückmeldungen unter stringenter Berücksichtigung
der Stellwerkslogik mindestens so sicher wie bei der Bestandstechnik
erfolgen muss. Die Daten sollen über ein sicheres Intranet
(https) übertragen werden.
-
Diese
Aufgabe wird durch Anspruch 1 erfindungsgemäß folgendermaßen
gelöst:
Jede Stellaktion eines Clients geht vom Server
des Stellwerks aus, entweder automatisch oder durch Handbedienung
des Fahrdienstleiters. Der Server muss hierfür einerseits
drahtlos die Stellbefehle an den Client senden und andererseits
die Durchführung der Befehle überwachen, wozu
vom Client an den Server Informationen über dessen Zustand
drahtlos zurückgemeldet werden. Hierfür wird zwischen
Befehls- und Überwachungsdaten unterschieden.
-
Zu
jedem übergeordneten Stellbefehl, der vom Server automatisch
und/oder durch manuelle Bedienung in den Server eingegeben wird,
gehören definierte einzelne Befehlsschritte, die Befehls-Transaktionen, die
vom Server an den Client in einer bestimmten Reihenfolge (Programm)
sicher übertragen und dort abgearbeitet werden müssen.
-
Als
Clients dienen alle Stelleinheiten (STE), Anschlusseinheiten (ASE)
oder Elementgruppen (EAM) der Außenanlage. Dazu gehören
u. a. Signale, Weichen, Bahnübergänge, Gleisfreimeldeanlagen,
Achszähler etc.
-
An
den Clients der Außenanlage sind Sensoren angebracht, die
den tatsächlichen Zustand der Clients ermitteln. Die zugehörigen Überwachungs-Transaktionsmeldungen
werden von den Clients an den Server gesendet.
-
Aufgrund
der drahtlosen Verbindung können keine Kabelschäden
durch Vandalismus oder Unfälle auftreten.
-
Die
Energieversorgung der Anlagen der Leit- und Sicherungstechnik erfolgt
vor Ort entweder über die transformierte Spannung aus der
Oberleitungsspeiseleitung, aus der örtlichen Energieversorgung
oder aus photovoltaischen Quellen, z. B. aus Dachflächen
der Betriebsstellen.
-
Erfindungsgemäß wird
mindestens eine Datenbank auf mindestens einem zentralen Stellwerksserver permanent
mit mindestens einer Datenbank auf mindestens einem Client, der
mindestens ein Element der Außenanlage steuert und überwacht,
synchronisiert. Die Synchronisation gewährleistet, dass
jederzeit eindeutig erfasst ist, ob der tatsächliche Zustand
des Clients mit dem von dem Stellbefehl definierten Sollzustand übereinstimmt
oder nicht.
-
Die
Server-Datenbank gilt als synchronisiert zu den Client-Datenbanken,
wenn alle vom Server vorgegebenen Befehle sicher vom Client abgearbeitet
und die zugehörigen Überwachungsmeldungen vom
Client an den Server erfolgreich übertragen wurden, so
dass der Sollzustand sowohl in der Server-Datenbank als auch in
der entsprechenden Client-Datenbank identisch erreicht ist.
-
Sind
die Datenbanken von Client und Server synchronisiert, kann mit ausreichender
Sicherheit davon ausgegangen werden, dass der Stellbefehl wie vorgesehen
vom Client abgearbeitet wurde.
-
Die
Kommunikation zwischen Server und den Clients ist quasi kontinuierlich,
d. h. die Server-Datenbank tauscht mit jeder Client-Datenbank permanent
Daten aus. Dies gewährleistet eine permanente Überwachung
der Stellelemente in der Außenanlage, ohne die der sichere
Betrieb des Stellwerks nicht möglich wäre.
-
Im
Allgemeinen reicht ein einziger Server mit einer einzigen Datenbank
in einem Stellwerk aus, um die zum Stellwerk gehörenden
Clients zu steuern und zu überwachen. Es ist aber auch
denkbar, dass mehr als eine Datenbank auf dem Server und oder mehrere
Server mit jeweils mindestens einer Datenbank im Stellwerk eingerichtet
sind, die entsprechend mit in die Kommunikation einzubeziehen sind.
Weiterhin ist es mit dem erfindungsgemäßen Verfahren
möglich, dass die Informationen zwischen zwei oder mehr
Stellwerken ausgetauscht werden, das heißt, dass von einem
Stellwerk aus die Clients anderer Stellwerke mitgesteuert werden.
-
Falls
ein bereits erteilter Stellbefehl zurückgenommen werden
soll oder im Notfall durch einen anderen ersetzt werden muss, löscht
der Server in der Befehls-Transaktionsliste alle Einträge
bezüglich der noch nicht ausgeführten Befehle.
Anschließend wird der neue Stellbefehl übermittelt.
-
Ein
besonderer Vorteil der Erfindung ist insbesondere, dass die Bestandstechnik
sowohl beim Elektronischen Stellwerk (ESTW) an sich als auch in
der Außenanlage weitestgehend beibehalten werden kann.
Es werden nur die Komponenten benötigt, die zum Senden
und Empfangen der Daten erforderlich sind. Außerdem ist
es prinzipiell möglich, unter Verwendung von Signalverstärkern
o. ä., Stellentfernungen zu realisieren, die weit über
die genannten 50 km hinausgehen.
-
Ansprüche
2 bis 5 beinhalten vorteilhafte Ausführungsformen der erfindungsgemäßen
Lösung aus Anspruch 1.
-
In
Anspruch 2 ist beschrieben, wie die Synchronisation der Datenbanken
vorteilhaft erfolgt. Voraussetzung der Synchronisation ist eine
eineindeutige Adressierung der beteiligten Datenbanken und der kommunizierten
Daten.
-
Bei
Aufnahme des Systembetriebs oder nach einem Ausfall muss der Client
neu gestartet werden. Beim Start des Clients wird im Server eine
eindeutige Laufzeit-ID für den Client generiert und dem
Client zugeteilt. Genauso hat jede Server-Datenbank eine eindeutige
ID. Somit kann die Kommunikation zwischen Server und Clients eineindeutig
adressiert werden.
-
Auch
jede Transaktion bekommt eine eindeutige Transaktions-ID. Die vom
Server kommenden Befehle erhalten eine Befehls-Transaktions-ID,
während die vom Client gesendeten Überwachungsmeldungen
eine Überwachungs-Transaktions-ID erhalten. Jede Transaktions-ID
ist auch innerhalb aller Clients eindeutig.
-
Eine
sogenannte Root-Liste in der mindestens einen Server-Datenbank enthält
die zu jedem Client gehörenden Daten, die von dieser Server-Datenbank
ver waltet werden. In der Root-Liste ist also für jeden
Client einzeln festgehalten, welche Befehls-Transaktionen vom Server
an den Client gesendet wurden, welche Befehls-Transaktionen vom
Client an den Server zurückgemeldet wurden und damit als
vom Client empfangen gelten, welchen Status der Client anhand seiner Überwachungsmeldungen
an den Server gesendet hat und ob der Server den Empfang der Überwachungsmeldungen
quittiert hat.
-
Jeder
zu überwachende Client besitzt jeweils eine eigene Datenbank,
in der der aktuelle Stand des Befehlsspeichers zur Verfügung
gestellt wird. Weiterhin besitzt die Datenbank Transaktionstabellen,
in denen alle Befehls-Transaktionen, die über den Server
im Stellwerk vorgenommen wurden, chronologisch hinterlegt werden,
zusammen mit den von den Sensoren gemeldeten Überwachungs-Transaktionen,
die zu den entsprechenden Befehlen gehören. In eigenen
Hilfstabellen sind diejenigen Befehls-Transaktionen gelistet, die
noch nicht abgearbeitet und somit noch nicht synchronisiert wurden.
Dort passen also die Befehls-Transaktionen noch nicht mit den zugehörigen Überwachungs-Transaktionen
zusammen.
-
Nachdem
ein Stellbefehl im Server ausgelöst wurde, läuft
die Synchronisation zwischen einem Server und einem Client folgendermaßen
ab:
- 1. Der Server übermittelt dem
zugehörigen Client zusammen mit der Laufzeit-ID eine Liste
aller zum Stellbefehl gehörenden Befehls-Transaktionen
und speichert diese in der Root-Liste.
- 2. Der Client mit der passenden Laufzeit-ID empfängt
die Befehls-Transaktionen und speichert diese in der Transaktions-Liste
seiner Datenbank.
- 3. Der Client beginnt mit der Abarbeitung der Befehlstransaktionen
in der Reihenfolge, in der sie in der Transaktions-Liste seiner
Datenbank gespeichert sind.
- 4. Der Client ermittelt mithilfe von Sensoren seinen Status
und speichert ihn in seiner Datenbank ab.
- 5. Der Client ermittelt, ob sich sein Status verändert
hat. Wenn ja, trägt er dies in der Transaktions-Liste seiner
Datenbank in all jenen Datenbankzeilen ein, die zu den die Statusänderung
auslösenden Befehlstransaktionen gehören.
- 6. Der Client bildet Quersummen der einzelnen Einträge
in der Transaktions-Liste seiner Datenbank und schickt diese Quersummenliste
zusammen mit der Laufzeit-ID als Statusmeldung zum Server.
- 7. Der Server empfängt die vom Client gesendete Statusmeldung.
- 8. Nach Empfang der Statusmeldung bildet der Server mit den
bisherigen Einträgen in der Root-Liste, die zu diesem Zeitpunkt
nur den Sollzustand beschreiben, ebenfalls die Quersummen aller
Einträge.
- 9. Nun vergleicht der Server die Quersummenliste, die der Client
gesendet hat, mit der Soll-Quersummenliste, die der Client schicken
müsste, wenn alle Datenbankzeilen korrekt abgearbeitet
wären. Stimmen die Quersummen überein, wurden
die Befehle erfolgreich abgearbeitet, was der Server durch einen
entsprechenden Eintrag mit der entsprechenden Laufzeit-ID in die
Root-Liste dokumentiert. Stimmen die Quersummen nicht überein,
werden die zugehörigen Befehle vom Server auf die neue
Befehls-Transaktionsliste geschrieben, die somit alle noch nicht
abgearbeiteten Befehle enthält.
- 10. Der Server sendet dem Client die neue Befehls-Transaktionsliste,
wie unter Punkt 1 beschrieben. Der Client vergleicht die neue Befehls-Transaktionsliste
mit der zuvor gespeicherten.
a. Zulässige Unterschiede
gibt es nur bei den Befehls-Transaktionen, die zuvor vom Client
erfolgreich abgearbeitet wurden. Dies wird somit dem Client vom
Server quittiert. Die entsprechenden Einträge können vom
Client nun gelöscht bzw. überschrieben werden.
Der Vorgang wird solange fortgesetzt, bis alle Befehle erfolgreich
abgearbeitet wurden. Danach ist die Root-Liste synchronisiert.
b.
Unzulässige Unterschiede zwischen der alten und neuen Befehls-Transaktionsliste,
wie z. B. das Auftauchen neuer Befehle oder die Nichteinhaltung
der chronologisch erforderlichen Reihenfolge, werden hierbei sicher
als Fehler erkannt und führen dazu, dass die Root-Liste
als nicht synchronisiert gilt. Dann wird der Synchronisierungsprozess,
und zwar bei dem zeitlich aktuellen Stellbefehl- oder bei der aktuellen Überwachungsmeldung
wieder aufgenommen. Dieser Prozess wird kontinuierlich durchgeführt
und endet erst bei Niederfahren des Systems oder bei Systemausfall.
Die Stellwerkslogik schreibt vor, in welcher Zeitspanne die Prozesse,
d. h. die Programmschritte, durchgeführt sein müssen,
so dass beispielsweise das Umlaufen einer Weiche zur Unzeit genauso
verhindert wird (z. B.: Einschalten Umlaufsperre), wie in einem
konventionellen Stellwerk. Auch die Anzahl der Umlaufversuche wird
durch die Stellwerkslogik vorgeschrieben und im System verarbeitet.
-
Erst
wenn die Root-Liste synchronisiert wurde, sind neue Stellbefehle
möglich.
-
Im
Anspruch 3 ist beschrieben, wie bei einem nicht sicherheitsrelevanten,
kurzzeitigen Ausfall eines Teilsystems die Befehlsfolge und deren
Abarbeitungsstand gesichert ist, so dass bei Wiederaufnahme des
Betriebs der Teilsysteme die Befehlsfolge ordnungsgemäß weitergeführt
wird.
-
Nach
der Stellbefehl-Eingabe werden die Stellbefehle im Stellwerksserver
gespeichert. Dann werden die Stellbefehle an die Clients gesendet.
Solange Sender und Empfänger online Kontakt zueinander
haben, können die Befehle vom Stellwerksserver aus direkt
zu den Clients gesendet werden. Die Clients nehmen die Befehle entgegen,
speichern sie und führen sie anschließend aus.
-
Besteht
kein Online-Kontakt zwischen Sender und Empfänger, arbeitet
die Vorrichtung im Offline-Modus. Die noch nicht ausgeführten
Stellbefehle werden solange beibehalten, bis wieder ein Kontakt
zwischen Sender und Empfänger existent ist. Ist der Kontakt
wiederhergestellt, werden die Befehle wie zuvor beschrieben bearbeitet.
-
Das
erfindungsgemäß verwendete sichere Rückbestätigungsverfahren
verläuft wie folgt:
Solange Sender und Empfänger
online Kontakt zueinander haben, bestätigen die Clients
die Ausführung der Befehle, sobald sie diese ausgeführt
haben.
-
Besteht
kein Online-Kontakt zwischen Sender und Empfänger, werden
die nicht ausgeführten Rückmeldungen solange beibehalten,
bis der Kontakt zwischen Sender und Empfänger wiederhergestellt
ist. Ist der Kontakt wiederhergestellt, werden die Rückbestätigungen
wie zuvor beschrieben gesendet.
-
Bei
einem Kommunikationsausfall, der länger als eine betrieblich
sicherheitsrelevante Zeitspanne dauert, kann die betriebliche Sicherheit
nicht mehr gewährleistet werden. Die Elemente der Außenanlage
müssen sofort automatisch in einen betrieblich sicheren
Grundzustand geschaltet werden.
-
Laut
Anspruch 4 wird als Protokoll zur Datenübertragung das
Internet Protocol (IP) verwendet.
-
Dies
hat den Vorteil, dass eine bewährte Technologie verwendet
wird, die gewährleistet, dass die zu übertragenden
Informationen sicher übertragen werden, bzw. im Fehlerfall
zuverlässig erfasst wird, dass Daten verlorengegangen sind.
-
Gemäß Anspruch
5 erfolgt die Kommunikation zwischen Stellwerksserver und Clients
vorzugsweise über das WireLess (Wimax, HSPA oder gleichartige)
Intranet der Bahn. Hierdurch sind Stellentfernungen von bis zu 50
km möglich, bei Verwendung von Signalverstärkern
o. ä., auch weit darüber hinaus.
-
Dazu
werden auf geeigneten Standorten, z. B. im Bereich der Bahn befindlichen
Liegenschaften oder Pachtgrund, HF-Antennen im Abstand einer für
das Ansteuern der Elemente notwendigen Ausleuchtung angebracht.
-
Die
betriebsmäßige Sicherheit der Stellbefehle und
der sicheren Rückbestätigungen wird erreicht durch
Hard- und Softwarekomponenten, welche über das genannte
WireLess (Wimax, HSPA oder gleichartige) Intranet der zentralen
Dienste (Hosts) kommunizieren.
-
Die
Erfindung wird nachstehend anhand eines Ausführungsbeispiels,
zweier Figuren und 5 Tabellen näher erläutert.
-
Die 1 zeigt
auf der linken Seite schematisch eine Stellwerks-Architektur, mit
Stellwerks-Server (3), kabelloser Datenübertragung über
WiMAX (4), den zugehörigen Gateways (5),
APs (6) und Clients (7), sowie die Elemente der
Außenanlage (8) mit Energieversorgung und den
Elementansteuermodulen mit Hochfrequenz-Empfängern, beziehungsweise
-Sendern. Auf der rechten Seite erfolgt die Datenübertragung
einmal über DSL (10) und andererseits über
Ethernet to Fiber Ring (11). Vor der Außenanlage
im rechten unteren Teilbild ist noch ein elektronisches Stellwerk,
ESTW A (9), geschaltet. Dieses ESTW wird also vom übergeordneten
Stellwerksserver (3) ferngesteuert.
-
2 zeigt
schematisch einen Weichenantrieb (12) mit den zugehörigen
Anschaltkontakten (14 und 15).
-
Wenn
nach dem Weichenanlauf nach circa zwei Umdrehungen die Antriebskontakte
Ak+ (14) abschalten, wird die Wicklung an N21 von N getrennt
und mit den beiden anderen Wicklungen zum Stern geschaltet. Der
Weichenantrieb läuft nun mit voller Kraft um. Spannung
und Strom können über einen Wandler an der Phase
L2 gemessen werden (13). Über N fließt
jetzt kein Strom mehr.
-
Beim
Erreichen der Linkslage schalten die Antriebskontakte Ak– (15)
und trennen die Sternschaltung wieder in den unverketteten Zustand
auf.
-
In
Tabelle 1 sind schematisch die Datenbanken von Server und Client
dargestellt, zusammen mit der drahtlosen Übertragung und
einer Weiche als beispielhaftes Element der Außenanlage.
Auf der Datenbank des Servers befinden sich die Transaktionstabellen.
Die Tabelle 1a ist die Transaktionstabelle der Clientdatenbank,
Tabelle 1b die Transaktionstabelle der Serverdatenbank. Tabelle
1a enthält alle Transaktionen von Überwachungsbefehlen,
die bereits durchgeführt, das heißt synchronisiert
wurden. Die Tabelle 1b enthält alle Transaktionen, die
noch durchgeführt werden müssen. Aus Tabelle 1b
werden im Speicher des Servers alle nächsten durchzuführenden
Befehle herausgelesen und über die drahtlose Verbindung
in den Befehlsspeicher des Clients übermittelt.
-
-
Die
Tabellen 2a bis 2d zeigen die Einträge in der Root-Liste
für die Befehlsschritte 1.1.5 und 1.1.6 des Beispielbefehls „Weiche
umstellen", die in den Transaktionslisten der Tabelle 1 aufgeführt
sind.
-
Betrachten
wir nun als Beispiel für einen Stellvorgang das Umstellen
einer Weiche im Zusammenhang mit dem Einstellen einer neuen Fahrstraße:
In
unserem Beispiel verfügt das Stellwerk über einen
einzigen Stellwerksserver mit einer Datenbank. Die Server-Datenbank
hat eine eindeutige ID. Die kabellose Datenübertragung
zu den Clients der Elemente der Außenanlage erfolgt über
ein WiMAX Intranet. Sowohl in Richtung vom Server zum Client als
auch in umgekehrter Richtung werden die Befehle über interne
Befehlsdatenspeicher abgespeichert. Die Entfernung der Außenanlage
beträgt ungefähr 50 km zum Stellwerk. Die Energieversorgung
der Anlagen der Leit- und Sicherungstechnik erfolgt vor Ort über
die transformierte Spannung aus der Oberleitungsspeiseleitung.
-
Zu
jedem Stellbefehl, der vom Server automatisch und/oder durch manuelle
Bedienung in den Server eingegeben wird, gehören definierte
einzelne Befehlsschritte, die Befehls-Transaktionen, die vom Server über WiMAX
an den Client in einer bestimmten Reihenfolge übertragen
werden.
-
Auf
der Datenbank des Servers gibt es eigene Befehls-Transaktionslisten,
mit deren Hilfe die vorgesehenen Befehlsschritte überwacht
und durchgeführt werden. In der Befehls-Transaktionsliste
Tok sind all jene Stellbefehle chronologisch hinterlegt, die über
den Server im Stellwerk bereits vorgenommen wurden. In der Hilfstabelle
Tnok1 sind alle noch nicht durchgeführten Befehlstransaktionen
enthalten.
-
An
den Clients der Außenanlage sind Sensoren angebracht, die
den tatsächlichen Zustand der Clients ermitteln. Der von
den Sensoren ermittelte Zustand wird mit Überwachungs-Transaktionen über
WiMAX von den Clients an den Server gemeldet.
-
Beim
letzten Start des Weichen-Clients wurde ihm vom Server eine eindeutige
Laufzeit-ID zugeordnet. Somit kann die Kommunikation zwischen Serverdatenbank
und dem Weichen-Client eineindeutig adressiert werden.
-
Auf
dem Weichen-Client ist wie bei jedem Client eine Datenbank eingerichtet.
Die Client-Datenbank stellt den aktuellen Stand des Befehlsspeichers
zur Verfügung. Weiterhin besitzt die Datenbank eine Transaktionstabelle
TCok, in denen alle Befehls-Transaktionen, die über den
Server im Stellwerk vorgenommen wurden, chronologisch hinterlegt
werden, zusammen mit den von den Sensoren gemeldeten Überwachungs-Transaktionen,
die zu den entsprechenden Befeh len gehören. In der Hilfstabelle
TCnok sind diejenigen Befehlstransaktionen gelistet, die noch nicht
abgearbeitet sind.
-
Im
Stellwerk wird eine neue Fahrstraße eingestellt, wozu unter
anderem auch eine Weiche umgestellt werden muss. Bis es zum Umstellen
der Weiche kommt, muss bereits eine Reihe anderer Befehle erfolgt
sein, die uns hier nur insoweit interessieren, als sie im Server
auf der Transaktions-Liste Tok der bereits durchgeführten,
das heißt synchronisierten Befehle gelistet sind. In der
Transaktions-Liste Tnok mit den noch durchzuführenden Befehlstransaktionen
steht nun unter anderem also auch der Befehl für die Weiche
umzulaufen.
-
Auf
der Server-Datenbank befindet sich die Root-Liste, mit der die zu
jedem Client gehörenden Daten verwaltet werden. So ist
die in unserem Beispiel zu betrachtende Weiche ebenfalls unter ihrer
Laufzeit-ID „30W01" in der Root-Liste aufgeführt
(s. Tabellen 2a bis 2d).
-
Die
Einträge bezüglich der Weiche in der Root-Liste
beschreiben die Zustände der Antriebskontakte Ak+ (14)
und Ak– (15), des Analog-Digitalwandlers an der
Phase L2. Zu jedem dieser Zustände ist weiterhin festgehalten,
welchen tatsächlichen Zustand die Sensoren der Weiche an
den Server gemeldet haben.
-
Zu
dem Befehl "Weiche nach Linkslage umstellen", den wir zur Vereinfachung
erst bei vollem Anlauf des Weichenantriebs in der Sternschaltung
betrachten, gehören die in Tabelle 1 gezeigten einzelnen
Befehlsschritte 1.1.1 bis 1.1.7, die in der angegebenen Reihenfolge
abgearbeitet werden müssen.
-
Zum
Befehlsschritt 1.1.5 gehören folgende Details:
- 1.) Abschalten der Antriebskontakte Ak+
- 2.) Überprüfen ob Sternschaltung vorliegt
(L1, L2 und L3)
-
Der
Analog-Digital Wandler wandelt hierbei analoge Signale aus den Ak
in digitale und gibt diese weiter an den Microcontroller, der über
eine serielle Schnittstelle an den Stellwerksrechner des ESTW angeschlossen
ist.
-
Bei
den Befehls- und Überwachungsschritten muss folgendes abgefragt
werden:
- • war die Befehlssendung erfolgreich?
- • war der Befehlsempfang erfolgreich?
- • wurde die Überwachungsmeldung erfolgreich
gesendet?
- • war die Überwachungsmeldung erfolgreich?
-
Demnach
sind die Schritte 1.1.1 bis 1.1.7, die zu dem Beispiel-Befehl 1
(Weiche nach Linkslage umstellen) gehören, in dieser Reihenfolge
in der Transaktions-Liste Tnok1 der Server-Datenbank aufgeführt
und werden nun zusammen mit der Laufzeit-ID über WiMAX
an den Weichen-Client übermittelt und außerdem
in der Root-Liste gespeichert. Die entsprechenden Zeilen der Root-Liste
vor dem Versand an den Client sehen wie in Tabelle 2a für
den Befehlsschritt 1.1.5 dargestellt aus. In der Root-Liste zeigt
die Transaktionsnummer 0 den Zustand vor Versenden des Befehlsschritts
1.1.5. Nachdem der Befehlsschritt 1.1.5 (Abschalten der Antriebskontakte
(14) Ak+) mit der Transaktionsnummer 1 gesendet wurde,
ist in der Spalte „Befehlssendung erfolgreich" nun ein „ja"
(digital 1) eingetragen.
-
-
-
-
Der
Weichen-Client mit der passenden Laufzeit-ID empfängt die
Befehlstransaktionen und speichert diese in der Transaktions-Liste
TCnok seiner Datenbank ab. In der gleichen Liste TCnok wird vom
Weichen-Client der zu jedem Befehlsschritt gehörende Zustand
eingetragen, der von den zugehörigen Sensoren ermittelt
wurde.
-
Der
Empfang der Befehlstransaktion 1.1.5 wird dem Server mit der Transaktionsnummer
2 quittiert, so dass nun auch in der Spalte „Befehlsempfang
erfolgreich" eine digitale 1 steht.
-
Der
Weichen-Client beginnt mit der Abarbeitung der Befehlstransaktionen
in der Reihenfolge, in der sie in der Transaktions-Liste TCnok seiner
Datenbank gespeichert ist. Als erstes werden also die Antriebskontakte
Ak+ abgeschaltet, und der Weichenantrieb in Sternschaltung an die
Phasen L1, L2 und L3 geschaltet.
-
Sobald
seine Sensoren ermitteln, dass sich der Zustand der Weiche verändert
hat, trägt der Weichen-Client dies in der Transaktions-Liste
TCnok ein.
-
Der
Weichen-Client bildet Quersummen der einzelnen Einträge
in der Transaktions-Liste TCnok und schickt diese Quersummenliste
zusammen mit der Laufzeit-ID als Statusmeldung QC zum Server.
-
Nach
Empfang der Statusmeldung (Transaktionsnummer 3 in der Root-Liste
in Tabelle 2b) bildet der Server mit den bisherigen Einträgen
in der Root-Liste, die zu diesem Zeitpunkt nur den Sollzustand beschreiben,
ebenfalls die Quersummen aller Einträge und speichert dies
als Quersummenliste QS.
-
Dann
vergleicht der Server die Quersummenlisten QC und QS. In den Zeilen,
in denen die Quersummen in der chronologisch erlaubten Reihenfolge übereinstimmen,
wurden die Befehle erfolgreich abgearbeitet. Für diese
Quersummen dokumentiert der Server in den zugehörigen Zeilen
der Root-Liste die Befehle als abgearbeitet, was in der Zeile „Transaktionsnummer
4" der Root-Liste in Tabelle 2b eingetragen wird.
-
Bei
den Zeilen, bei denen die Quersummen nicht übereinstimmen,
werden die zugehörigen Befehle vom Server auf die neue
Befehls-Transaktions-Liste geschrieben, die somit alle noch nicht
abgearbeiteten Befehle enthält.
-
Der
Server sendet dem Weichen-Client die neue Befehls-Transaktions-Liste
Tnok2. Der Weichen-Client vergleicht die neue Befehls-Transaktionsliste
Tnok2 mit der zuvor gespeicherten Tnok1. Zulässige Unterschiede
gibt es nur bei den Befehls-Transaktionen, die zuvor vom Weichen-Client
erfolgreich abgearbeitet wurden. Dies ist bei Befehlsschritt 1.1.5
und Überwachungsmeldungsschritt 1.1.5 nun der Fall. Damit
ist dem Weichen-Client vom Server quittiert worden, dass dieser
die Information über die Ausführung des Befehlsschritts 1.1.5
und des Überwachungsmeldungsschritts 1.1.5 erhalten hat.
-
Die
entsprechenden Einträge in der Befehls-Transaktionsliste
TCnok werden vom Weichen-Client nun gelöscht. Außerdem
dokumentiert der Weichen-Client die abgearbeiteten Befehle in der
Befehls-Transaktionsliste TCok.
-
Der
Weichen-Client fährt mit der Bearbeitung der Befehls-Transaktionsliste
Tnok ab dem nächsten Befehlsschritt 1.1.6 des Befehls 1
und der zugehörigen Überwachungsmeldung fort.
In den Tabellen 2c und 2d sind wieder die Einträge in der
Root-Liste dargestellt, mit den Transaktionsnummern 5 bis 8.
-
Nach
Erreichen der neuen Lage der Weiche sind die Antriebskontakte Ak+
wieder umgeschaltet und der Weichenlaufmelder zeigt die Unterbrechung
des Stellstroms an.
-
Erneut
ermitteln die Sensoren, dass sich der Zustand der Weiche verändert
hat. Der Weichen-Client trägt dies in der Transaktions-Liste
TCnok ein. Der Weichen-Client bildet wieder Quersummen der einzelnen Einträge
in der Transaktions-Liste TCnok und schickt diese Quersummenliste
zusammen mit der Laufzeit-ID als Statusmeldung QC zum Server.
-
Nach
Empfang der Statusmeldung bildet der Server mit den bisherigen Einträgen
in der Root-Liste, die zu diesem Zeitpunkt den zuvor erreichten
Zustand beschreiben, ebenfalls die Quersummen aller Einträge
und speichert dies als Quersummenliste QS.
-
Dann
vergleicht der Server die Quersummenlisten QC und QS. In den Zeilen,
in denen die Quersummen in der chronologisch erlaubten Reihenfolge übereinstimmen,
wurden die Befehle erfolgreich abgearbeitet. Für diese
Quersummen dokumentiert der Server in den zugehörigen Zeilen
der Root-Liste die Befehle wie in Tabelle 2d gezeigt, als abgearbeitet.
-
Die
neue Befehls-Transaktionsliste ergibt sich nun als Differenzliste
Tnok3, die vom Server an den Weichen-Client gesendet wird. Der Weichen-Client
vergleicht die neue Befehls-Transaktionsliste Tnok3 mit der zuvor
gespeicherten Tnok2. Zulässige Unterschiede gibt es nur
bei den Befehls-Transaktionen, die zuvor vom Weichen-Client erfolgreich
abgearbeitet und vom Server quittiert wurden. Dies ist diesmal bei
dem Befehlsschritt 1.1.6 der Fall. Damit ist dem Weichen-Client
vom Server quittiert worden, dass dieser die Information über
die Ausführung der Befehlsschritte bis 1.1.6 erhalten hat.
Die entsprechenden Einträge in der Befehls-Transaktionsliste
TCnok werden vom Weichen-Client nun gelöscht. Außerdem
dokumentiert der Weichen-Client die abgearbeiteten Befehle in der
Befehls-Transaktionsliste TCok.
-
Nach
analoger Abarbeitung aller zum Befehl „Weiche in Linkslage
umstellen" gehörenden Befehlsschritte steht in den zugehörigen
Zeilen der Root-Liste in der letzten Zeile der Befehls- und Überwachungstransaktionen
in allen Feldern „ja" (digital 1).
-
Da
dies nun bei der betrachteten Weiche für alle relevanten
Zeilen der Root-Liste gilt, ist die Root-Liste synchronisiert. Der
Weichen-Client hat nun alle Befehle abgearbeitet.
-
Erst
ab diesem Zeitpunkt sind wieder neue Stellbefehle möglich.
-
Um
den Umgang mit Fehlern zu beschreiben, betrachten wir nun den Fall,
dass nach Abarbeitung der Befehlsschritte 1.1.1 bis 1.1.3 der Befehl
1.1.4 als nicht abgearbeitet gemeldet wird, und trotzdem die Sensoren
einen Zustand erfassen, bei dem Befehl 1.1.5 abgearbeitet sein müsste.
-
Beim
Vergleich der Quersummenlisten QC und OS würde sich also
folgendes Bild ergeben:
Die chronologisch erlaubte Reihenfolge
ist ab Befehlsschritt 1.1.4 unterbrochen. Deshalb würde
der Server nur für die Quersummen, die zu den Befehlschritten
1.1.1 bis 1.1.3 gehören, in den zugehörigen Zeilen
der Root-Liste die Befehle als abgearbeitet dokumentieren. Die neue
Befehls-Transaktionsliste würde bei Befehlsschritt 1.1.4
beginnen. Bei Wiederholung des Fehlers würde eine entsprechende
Fehlermeldung ausgegeben werden. Die Behandlung von Wiederholungen
der Fehlermeldungen kann programmgemäß entweder
durch Vorgabe eines Zeitfensters oder durch die Anzahl der Wiederholungen
vorgegeben werden. Bei Überschreitung dieser Parameter
reagiert das System mit der Anweisung den Stellbefehl zu negieren
und dieses dem Stellrechner mitzuteilen.
-
Die
Kommunikation zwischen Client und Server läuft in Wirklichkeit
wesentlich schneller ab als hier beschrieben. Hier wurde der Anschaulichkeit
halber ein Zeitintervall gewählt, das groß genug
ist, um Veränderungen in den beteiligten Datenbanktabellen
deutlich erkennen zu können. Tatsächlich werden
die Daten zwischen Client und Server jedoch schon innerhalb von
ca. 200 Millisekunden (abhängig von der Netzbelastung) ausgetauscht.
-
Der
Takt des Datenaustauschs zwischen Client und Server muss mindestens
so schnell sein, dass gewährleistet ist, dass sicherheitsrelevante
Fehler innerhalb einer von betrieblichen Vorgaben abhängigen
Zeit sicher erkannt werden können. Im Netz der Deutschen
Bahn AG beträgt diese Zeit etwa 1,8 Sekunden. Solange dauert
es beispielsweise, bis bei einem Stromausfall alle Signale auf Halt
fallen.
-
Bei
einem nicht sicherheitsrelevanten, kurzzeitigen Ausfall – beispielsweise
des Empfängers des Weichenclients – ist die Befehlsfolge
und deren Abarbeitungsstand folgendermaßen gesichert:
Nach
der Stellbefehl-Eingabe werden die Stellbefehle im Stellwerksserver
gespeichert. Dann werden die Stellbefehle wie beschrieben an den
Weichen- Client gesendet. Solange Sender und Empfänger online
Kontakt zueinander haben, können die Befehle vom Stellwerksserver
aus direkt zum Weichen-Client gesendet werden. Der Weichen-Client
kann nun die Befehle nicht entgegennehmen, was mithilfe des verwendeten
Internet Protokolls sogleich entdeckt wird.
-
Das
Verfahren arbeitet nun im Offline-Modus. Die noch nicht ausgeführten
Stellbefehle werden auf dem Server solange beibehalten, bis wieder
ein Kontakt zwischen Sender und Empfänger existent ist.
-
Der
Weichen-Client arbeitet unterdessen anhand der immer noch gültigen
zuvor empfangenen Befehls-Transaktionsliste, die er in seine eigene
Befehls-Transaktionsliste TCnok übernommen hat, weiter.
Er speichert die entsprechenden Statusmeldungen wie normal ab, aber
ohne die rückläufigen Überwachungsmeldungen
an den Server zu schicken.
-
Ist
der Kontakt innerhalb der sicherheitsrelevanten Zeit wiederhergestellt,
werden die Daten wie zuvor beschrieben wieder ausgetauscht.
-
Ein
weiteres Beispiel soll zeigen, wie von einem Stellwerksserver aus
Clients bedient werden können, die zu einem anderen Stellwerk
gehören.
-
Das
Stellwerk A sei ein Nachbarstellwerk zu Stellwerk B. Bei einem Ausfall
des Stellwerks B ist es nun möglich, dass das Stellwerk
A die Clients des Stellwerks B steuert.
-
Hierfür
muss lediglich die Root-Liste im Stellwerk A mit den Clients des
Stellwerks B erweitert werden. Aufgrund der erfindungsgemäßen
eindeutigen Adressierung sowohl aller Server als auch aller Clients
ist dies problemlos durch Zuweisung von Lese- und Schreibrechten
der Stell- und Überwachungsmeldungen zu den jeweiligen
Nachbarstellwerken möglich.
-
Im
ungestörten Betrieb der beiden benachbarten Stellwerke
werden die derzeit aktuellen Befehle und Überwachungsmeldungen
zur Information untereinander ausgetauscht. Dadurch weiß jedes
Stellwerk, welche Aktionen im benachbarten Stellwerk anliegen und
wie der Zustand der zugehörigen Clients ist.
-
Bei
einer ungeplanten, plötzlichen Übergabe der Clients
des Stellwerks B an den Server des Stellwerks A müssen
folgende Regeln beachtet werden:
Die Befehlstransaktion, die
gerade vom Server des Stellwerks A bearbeitet wird, muss auf jeden
Fall zunächst zu Ende geführt, das heißt
synchronisiert werden. Gibt es weitere noch zu synchronisierende
Transaktionen im Stellwerk A, werden diese zuerst bearbeitet.
-
Dann übernimmt
der Stellwerks-Server im Stellwerk A den letzten Stand der Befehlstransaktionen
des Servers im Stellwerk B und erfasst den Zustand der Clients im
Stellwerk B. Anschließend benutzt das Stellwerk A die erweiterte Root-Liste
und verfährt so, als würden die Clients des Stellwerks
B zum Stellwerk A gehören.
-
Wenn
die Störung im Stellwerk B behoben ist, wird der zu Stellwerk
B gehörende erweiterte Teil der Root-Liste vom Stellwerksserver
A geprüft und synchronisiert. Dabei werden alle die Befehle
ignoriert, die bereits vom Server B quittiert und demnach abgearbeitet
sind.
-
Darüber
hinaus ist es durch die Verwendung einer Datenbank, in der alle
Stellwerksserver und Clients der Außenanlagen eineindeutig
und zentral gespeichert sind (z. B.: in einer Betriebszentrale),
erfindungsgemäß möglich, durch Zuweisung
von Bedienrechten auch Clients fremder (nachbarlicher) Server- oder
ganze fremde Stellbezirke regulär oder im Notfall mitzusteuern.
-
- 1
- Sender
- 2
- Wired
IP Network
- 3
- Server
- 4
- WiMAX-Verbindung
mit kabelloser Datenübertragung
- 5
- WiMAX
und WiFi Gateways
- 6
- WiMAX
und Wi-Fi APs
- 7
- WiMAX
und Wi-Fi-Clients
- 8
- Stellwerks-Außenanlage
- 9
- Ferngesteuertes
Stellwerk mit Außenanlage
- 10
- DSL-Verbindung
- 11
- Ethernet
to Fiber Ring
- 12
- Weichenantrieb
- 13
- Erkennung/Signalauswertung
- 14
- Kontakte
Ak+
- 15
- Kontakte
Ak–
-
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 4107639
A1 [0008]
- - DE 102004062987 A1 [0010]
- - EP 1420566 A1 [0012]
