DE102012216391A1

DE102012216391A1 - Kommunikation zwischen Wagen eines Schienenfahrzeugs

Info

Publication number: DE102012216391A1
Application number: DE102012216391.3A
Authority: DE
Inventors: Carsten Hasselkuss; Markus Dymek; Udo Rabeneck; Christian Wilke
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2012-09-14
Filing date: 2012-09-14
Publication date: 2014-03-20
Also published as: WO2014040880A1

Abstract

Es wird vorgeschlagen, eine Kommunikation von insbesondere ETCS-fähigen Fahrzeugrechnern, die in unterschiedlichen Wagen eines Schienenfahrzeugs vorhanden sind, über eine mobile Kommunikationsschnittstelle zu koppeln. Hierbei werden vorzugsweise einer der Fahrzeugrechner als Master-Fahrzeugrechner und die anderen Fahrzeugrechner des Schienenfahrzeugs als Slave-Fahrzeugrechner bestimmt. Die Koordination der Kommunikation sowie der Vergabe vorbestimmter Aufgaben, z.B. Funktions- und Bremsprüfungen, veranlasst der Master-Fahrzeugrechner. Hierbei ist es von Vorteil, dass die mobile Kommunikationsschnittstelle, z.B. in Form des GSM-R Netzes oder eines Nachfolgenetzes, genutzt wird, um eine flexible, zeiteffiziente und kostengünstige Möglichkeit zu schaffen, Funktions- und Bremsprüfungen automatisiert an allen in Frage kommenden Stellen des Schienenfahrzeugs durchführen zu können.

Description

Die Erfindung betrifft einen Wagen zum Einsatz in einem Schienenfahrzeug, ein Verfahren zur Kommunikation zwischen Wagen eines Schienenfahrzeugs sowie ein entsprechendes Schienenfahrzeug, ein Computerprogrammprodukt und ein computerlesbares Speichermedium.
Das "European Train Control System" (ETCS) ist eine Komponente eines einheitlichen europäischen Eisenbahnverkehrsleitsystems, das unter dem Buchstabenkürzel ERTMS entwickelt wurde. Die zweite technische Komponente dieser digitalen Bahntechnologie ist das Bahn-Mobilfunksystem GSM-R. ETCS soll die Vielzahl der in den Ländern eingesetzten Zugsicherungssysteme ablösen, mittelfristig im Hochgeschwindigkeitsverkehr Verwendung finden und langfristig im gesamten europäischen Schienenverkehr umgesetzt werden (http://de.wikipedia.org/wiki/ETCS).
Alle ETCS Fahrzeugeinrichtungen im Schienenfahrzeug (Zugverband) sollen vom besetzten Führerstand eines Zugverbandes aus ferngesteuert werden können, um Funktionstests und Bremstests in den einzelnen Anlagen durchzuführen. Dies ist nötig, um vorgegebene Prüfzyklen (z.B. einmal pro Tag) zur Fehlerentdeckung in den ETCS-Fahrzeugeinrichtungen einhalten zu können. Eine solche Funktions- und Bremsprüfung kann z.B. je nach Konfiguration der Bremsanlage mehrere Minuten andauern.
Hierbei gibt es das Problem, dass entweder keine zugweiten Bussysteme vorhanden sind, um die ETCS-Fahrzeugeinrichtungen logisch miteinander zu verbinden und eine einheitliche Funktionsprüfung über das Bussystem zu koordinieren. Eine Montage bzw. Nachrüstung eines solchen Bussystems wäre mit erheblichem Aufwand und Kosten verbunden.
Andererseits besteht das Problem, dass es zwar zugweite Bussysteme gibt, diese aber nicht auf einfache Art und Weise an die ETCS-Fahrzeugeinrichtungen angeschlossen werden können. Entsprechend wären aufwändige und teure Adaptionsmechanismen nötig z.B. in Form von Buskopplern oder Gateways. Ein weiteres Problem in Bezug auf bestehende Bussysteme liegt in der Belastung des Busses mit zusätzlichen Daten.
In bestehenden Lösungen müssen in dem Schienenfahrzeug die einzelnen mit ETCS ausgerüsteten Führerstände mit Personal besetzt werden und die Funktionsprüfung muss manuell ausgelöst werden. Dies bedeutet einen erheblichen zusätzlichen Zeitaufwand in der vorbereitenden Aktivierung des Schienenfahrzeugs, z.B. bei einem Wechsel zwischen einzelnen Steuerwagen oder Triebfahrzeugen. Ein weiterer Nachteil bestehender Lösungen ist es, dass erst beim Besetzen eines Führerstandes eine Prüfung von der ETCS-Fahrzeugeinrichtung veranlasst werden kann, wodurch es zu Verzögerungen und damit Behinderungen im betrieblichen Ablauf und zu Fahrplanverspätungen kommen kann.
Es gibt Vorschläge, ein zugweites Bussystem zu nutzen derart, dass von einer ETCS-Einrichtung per Buskommandos eine andere ETCS-Einrichtung, die ebenfalls an das Bussystem angeschlossen ist, zur Ausführung einer Funktionsprüfung aufgefordert und der Ablauf überwacht wird. Hierbei ist es jedoch von Nachteil, dass ein zugweites Bussystem zu diesem Zweck ausgestaltet sein muss. Eine Umrüstung bestehender Schienenfahrzeuge würde jedoch zu erheblichen Ausrüstungs- und Umbaukosten führen. Insbesondere im Hinblick auf eine flexible, lokbespannte Zugzusammenstellung müsste eine Vielzahl von Wagen mit einem derartigen Bussystem ausgerüstet sein.
Die Aufgabe der Erfindung besteht darin, die vorstehend genannten Nachteile zu vermeiden und insbesondere eine effiziente Möglichkeit anzugeben, eine Funktionsprüfung in einem ETCS-Wagen durchführen zu können.
Diese Aufgabe wird gemäß den Merkmalen der unabhängigen Ansprüche gelöst. Bevorzugte Ausführungsformen sind insbesondere den abhängigen Ansprüchen entnehmbar.
Zur Lösung der Aufgabe wird ein Wagen zum Einsatz in einem Schienenfahrzeug angegeben

– mit einem Fahrzeugrechner,
– wobei anhand des Fahrzeugrechners über eine mobile Kommunikationsschnittstelle Daten an einen Fahrzeugrechner eines anderen Wagens desselben Schienenfahrzeugs übermittelbar sind.

Der Fahrzeugrechner kann auch als ein European Vital Computer (EVC) ausgeführt sein bzw. einen solchen umfassen. Insbesondere können der Fahrzeugrechner und die mobile Kommunikationsschnittstelle in einer gemeinsamen Einheit verortet sein. Beispielsweise kann der Fahrzeugrechner die mobile Kommunikationsschnittstelle, z.B. ein GSM-Modul (insbesondere ein GSM-R-Modul), aufweisen oder mit einer solchen verbunden sein. Über die mobile Kommunikationsschnittstelle tritt der Fahrzeugrechner mit einem anderen Fahrzeugrechner desselben Schienenfahrzeugs in Verbindung und überträgt und/oder empfängt Daten. Die mobile Kommunikationsschnittstelle kann eine Verbindung zu einem Funknetzwerk, z.B. einem Mobilfunknetzwerk wie GSM-R oder einem anderen Mobilfunknetzwerk, herstellen. Insbesondere können auch Mobilfunknetzwerke nach künftigen Kommunikationsstandards für die vorliegende Erfindung eingesetzt werden.
Dieser Ansatz erlaubt eine flexible und automatisierte Kommunikation zwischen mehreren Fahrzeugrechnern ein und desselben Schienenfahrzeugs über eine Funkschnittstelle, insbesondere eine Funkschnittstelle eines mobilen Kommunikationsnetzwerks. Basierend auf einer solchen Kommunikation ist es möglich, z.B. Prüfläufe – umfassend z.B. Funktions- und/oder Bremstests – über die einzelnen Fahrzeugrechner auszulösen, zu koordinieren und zu überwachen. Eine manuelle Ausführung der Tests vor Ort, z.B. in den mehreren Führerkabinen des Schienenfahrzeugs, erübrigt sich hiermit. Dies spart Zeit und erhöht z.B. die Flexibilität hinsichtlich der Bereitstellung bzw. der Weiterfahrt des Schienenfahrzeugs.
Hierbei sei angemerkt, dass das Schienenfahrzeug (auch bezeichnet als "Zug") mindestens zwei Wagen aufweist, wobei der Wagen ein Triebfahrzeug, ein Reisewagen, ein Güterwagen oder eine Kombination aus derartigen Abteilen oder Funktionen sein kann. Das Triebfahrzeug weist eine Führerkabine (auch bezeichnet als Bedienplatz) auf und kann mit oder ohne Antrieb ausgeführt sein. Das Triebfahrzeug kann insbesondere eine Lokomotive sein. Jeder Wagen des Schienenfahrzeugs kann mit einem Fahrzeugrechner ausgestattet sein; stellt der Fahrzeugrechner (ggf. mit der mobilen Kommunikationsschnittstelle) eine ETCS-Funktion bereit, wird dieser hier auch als ETCS-Wagen bezeichnet. Grundsätzlich ist es möglich, dass nur die Triebfahrzeuge je einen Fahrzeugrechner (ggf. mit der mobilen Kommunikationsschnittstelle) bzw. dass auch einzelne Wagen, die keine Triebfahrzeuge sind, derartige Fahrzeugrechner (ggf. mit der mobilen Kommunikationsschnittstelle) aufweisen.
Eine Weiterbildung ist es, dass der Fahrzeugrechner die Rolle eines Master-Fahrzeugrechners oder eines Slave-Fahrzeugrechners erhält infolge einer Kommunikation mit einem Server.
Der Master-Fahrzeugrechner übernimmt hierbei vorteilhaft die Koordination der Kommunikation mit den Slave-Fahrzeugrechnern des Schienenfahrzeugs. Somit ist eine geordnete Reihenfolge der Kommunikation und z.B. der dadurch veranlassten Prüfläufe sichergestellt.
Es gibt eine Vielzahl von Mechanismen, die eine eindeutige Auswahl eines einzigen Fahrzeugrechners der mehreren Fahrzeugrechner des Schienenfahrzeugs sicherstellen. Die Selektion des Master-Fahrzeugrechners kann mit Hilfe des Servers oder direkt durch den Server erfolgen. So verfügt der Server z.B. über mehr Informationen als die einzelnen Fahrzeugrechner des Schienenfahrzeugs; auch kennt der Server die Zusammensetzung des Schienenfahrzeugs, d.h. dem Server ist z.B. bekannt, welche Wagen in dem Schienenfahrzeug existieren und/oder welche dieser Wagen einen Fahrzeugrechner aufweisen. In Kenntnis der Fahrzeugrechner, des Schienenfahrzeugs und des Fahrplans kann der Server z.B. denjenigen Fahrzeugrechner zum Master-Fahrzeugrechner bestimmen, der

– in Fahrtrichtung der erste Fahrzeugrechner ist oder
– die kleinste (oder die größte) eindeutige Kennung aufweist,
– in einem Wagen angeordnet ist, der im Hinblick auf zukünftige Zugzusammensetzungen am längsten in dem Schienenfahrzeug verbleibt,
– etc.

Dies sind nur einige wenige von einer Vielzahl von Möglichkeiten, einen einzelnen Fahrzeugrechner aus einer Gruppe von Fahrzeugrechnern (nämlich den Fahrzeugrechnern, die in Wagen des Schienenfahrzeugs vorhanden sind) zu dem Master-Fahrzeugrechner zu machen, der dann die Koordination der Kommunikation mit den Slave-Fahrzeugrechnern dieses Schienenfahrzeugs durchführt.
Hierbei sei angemerkt, dass der Server hier beispielhaft für einen Rechner oder ein Rechnernetzwerk steht, mit dem der Fahrzeugrechner des Wagens (bzw. die Fahrzeugrechner der mehreren Wagen des Schienenfahrzeugs) z.B. über die mobile Kommunikationsschnittstelle kommunizieren. Der Server kann selbst verteilt oder vervielfacht ausgeführt sein und z.B. über eine bestimmte Adresse, Kennung und/oder Nummer von den Fahrzeugrechnern angesprochen werden. Die konkrete Hardware-Realisierung des Servers kann auf viele unterschiedliche Arten erfolgen; beispielsweise kann der Server verteilt auf einer Vielzahl von Maschinen oder er kann auf einer einzelnen Maschine implementiert sein.
Eine andere Weiterbildung ist es,

– dass über die mobile Kommunikationsschnittstelle von dem Fahrzeugrechner an den Server eine Anfrage betreffend das Schienenfahrzeug übermittelbar ist und
– dass der Fahrzeugrechner von dem Server in Folge der Anfrage eine Nachricht betreffend das Schienenfahrzeug erhält.

Beispielsweise kann die Nachricht Daten (z.B. Telefonnummern) der weiteren in dem Schienenfahrzeug vorhandenen Fahrzeugrechner enthalten. In diesem Fall kennt jeder Fahrzeugrechner alle anderen Fahrzeugrechner des Schienenfahrzeugs.
Insbesondere ist es eine Weiterbildung, dass die Nachricht mindestens eine der folgenden Informationen umfasst:

– eine Position des Schienenfahrzeugs,
– eine Position des Wagens innerhalb des Schienenfahrzeugs,
– eine Zusammensetzung des Schienenfahrzeugs,
– weitere Fahrzeugrechner und Kommunikationsdaten der weiteren Fahrzeugrechner des Schienenfahrzeugs.

Insbesondere ist es eine Option, dass der Server den Master-Fahrzeugrechner auswählt und den Fahrzeugrechnern des Schienenfahrzeugs mitteilt, wer der Master-Fahrzeugrechner dieses Schienenfahrzeugs ist. In diesem Fall können die anderen Fahrzeugrechner des Schienenfahrzeugs jeweils die Rolle des Slave-Fahrzeugrechners annehmen. Der Master-Fahrzeugrechner erhält von dem Server die Kennungen (z.B. Nummern) aller Slave-Fahrzeugrechner, die er ansprechen können soll. Der Master-Fahrzeugrechner kann somit jeden einzelnen Slave-Fahrzeugrechner über diese Kennung direkt erreichen und ihn Veranlassen, einen vorgegebene Aktion (z.B. einen Prüflauf) durchzuführen.
Auch ist es eine Weiterbildung, dass der Fahrzeugrechner eine ETCS-Funktion bereitstellt.
Ferner ist es eine Weiterbildung, dass die an den Fahrzeugrechner des anderen Wagens übermittelten Daten eine Funktions- und/oder Bremsprüfung des anderen Wagens veranlassen.
Im Rahmen einer zusätzlichen Weiterbildung übermittelt der Fahrzeugrechner des anderen Wagens nach durchgeführter Funktions- und/oder Bremsprüfung eine Rückmeldung an den Fahrzeugrechner.
Eine solche Rückmeldung kann einen mehr oder weniger detaillierten Bericht umfassen über die erfolgreich oder nicht erfolgreich durchgeführten Aktionen. Für Dokumentationszwecke kann die Rückmeldung gespeichert und ggf. auch an den Server oder eine andere Stelle mittels der mobilen Kommunikationsschnittstelle übertragen werden.
Eine nächste Weiterbildung besteht darin, dass der Fahrzeugrechner eine Kommunikation mit mehreren anderen Fahrzeugrechnern, die jeweils in einem Wagen des Schienenfahrzeugs angeordnet sind, koordiniert.
Eine Ausgestaltung ist es, dass der Fahrzeugrechner die Rolle eines Master-Fahrzeugrechners erhält infolge einer Aktivierung eines Führerstands des Wagens.
Dies ist eine weitere Möglichkeit, eindeutig einen Fahrzeugrechner zum Master-Fahrzeugrechner zu machen. Sofern nur ein Führerstand des Schienenfahrzeugs aktiv sein kann, ist es möglich, automatisch demjenigen Fahrzeugrechner die Rolle des Master-Fahrzeugrechners zuzuweisen, der in dem Wagen angeordnet ist, dessen Führerstand zuerst aktiviert wird.
Eine alternative Ausführungsform besteht darin, dass der Wagen eine der folgenden Komponenten eines Schienenfahrzeugs ist:

– eine Lokomotive;
– ein Triebwagen mit Antrieb;
– ein Triebwagen ohne Antrieb;
– ein Reisewagen;
– ein Güterwagen.

Auch Kombinationen der vorstehenden Komponenten können Teil eines Wagens sein: z.B. kann ein Triebwagen ohne Antrieb einen Führerstand und mindestens eine Kabine zum Transport von Passagieren aufweisen.
Die vorstehende Aufgabe wird auch gelöst mittels eines Schienenfahrzeugs, das mehrere Wagen wie hierin beschrieben aufweist.
Ferner wird die Aufgabe gelöst mittels eines Verfahrens zur Kommunikation zwischen Wagen eines Schienenfahrzeugs, wobei anhand eines ersten Fahrzeugrechners, der in einem ersten Wagen angeordnet ist, über eine mobile Kommunikationsschnittstelle Daten an einen zweiten Fahrzeugrechner, der in einem zweiten Wagen desselben Schienenfahrzeugs angeordnet ist, übermittelt werden.
Die vorstehenden Ausführungen gelten für das Verfahren entsprechend.
Die hier vorgestellte Lösung umfasst ferner ein Computerprogrammprodukt, das direkt in einen Speicher eines digitalen Computers ladbar ist, umfassend Programmcodeteile, die dazu geeignet sind, Schritte des hier beschriebenen Verfahrens durchzuführen.
Weiterhin wird das oben genannte Problem gelöst mittels eines computerlesbaren Speichermediums, z.B. eines beliebigen Speichers, umfassend von einem Computer ausführbare Anweisungen (z.B. in Form von Programmcode), die dazu geeignet sind, dass der Computer Schritte des hier beschriebenen Verfahrens durchführt.
Die oben beschriebenen Eigenschaften, Merkmale und Vorteile dieser Erfindung sowie die Art und Weise, wie diese erreicht werden, werden klarer und deutlicher verständlich im Zusammenhang mit der folgenden schematischen Beschreibung von Ausführungsbeispielen, die im Zusammenhang mit den Zeichnungen näher erläutert werden. Dabei können zur Übersichtlichkeit gleiche oder gleichwirkende Elemente mit gleichen Bezugszeichen versehen sein.
Es zeigt:
1 ein schematisches Schaubild, das beispielhaft eine funkgesteuerte ETCS-Funktions- und/oder Bremsprüfung veranschaulicht.
Bekannte ETCS-Fahrzeugeinrichtungen, auch bezeichnet als ETCS-Fahrzeugrechner (oder "EVC" für European Vital Computer), nachfolgend bezeichnet als Fahrzeugrechner, verfügen bereits für die Kommunikation mit ETCS-Streckeneinrichtungen über GSM-R-Funkgeräte (hierbei handelt es sich um eine sogenannte "Level 2 – Funktionalität").
Die bestehende Ausrüstung kann genutzt werden, damit der Fahrzeugrechner im besetzten Führerstand (bezeichnet als Master-EVC) eine mobilfunkgestützte Kommunikation, z.B. eine SMS-basierte Kommunikation (oder alternativ z.B. eine kontinuierliche oder quasi-kontinuierliche Funkverbindung) zu jeweils einem der anderen Fahrzeugrechner des Schienenfahrzeugs aufbauen kann.
1 zeigt ein schematisches Schaubild, das beispielhaft eine funkgesteuerte ETCS-Funktions- und/oder Bremsprüfung veranschaulicht. Eine solche Prüfung erfolgt im Rahmen eines Prüflaufs, der vorzugsweise zu vorgegebenen Zeitpunkten und/oder mit einer vorgegebenen Regelmäßigkeit durchgeführt wird.
Ein Schienenfahrzeug 101 umfasst ein Triebfahrzeug 102 mit einem Master-EVC 105, wobei beispielhaft der Führerstand dieses Triebfahrzeugs 102 mit einer Person besetzt ist. Weiterhin umfasst das Schienenfahrzeug 101 ein Triebfahrzeug 104 mit einem Slave-EVC 106 und einen Reisewagen 103. Die Triebfahrzeuge 102 und 104 können mit oder ohne Antrieb ausgeführt sein; auch können diese Triebfahrzeuge 102 und 104 z.B. mindestens ein Abteil eines Reisewagens enthalten. Grundsätzlich ist es möglich, dass zusätzliche Wagen, sei es Triebwagen oder sonstige Wagen, Teil des Schienenfahrzeugs 101 sind. Insbesondere können mehrere Wagen mit Fahrzeugrechnern (Slave-EVCs) vorgesehen sein.
Mit der Aktivierung des Führerstands durch den Benutzer kann dem Fahrzeugrechner dieses Triebfahrzeugs die Rolle des Master-EVCs zugewiesen werden. Da nicht mehrere Führerstände eines Zugs zur gleichen Zeit besetzt sein sollen (bzw. aktiviert werden können), kann so die Rolle des einen Master-EVCs und der ggf. mehreren Slave-EVCs eindeutig festgelegt werden.

Nachfolgend werden die in 1 gezeigten Schritte erläutert:

Schritt 210:	Der Master-EVC 105 sendet eine Anfrage
	betreffend die Zugkonfiguration über ein
	GSM-R Netzwerk 107 an einen Server 108, der
	vorzugsweise als ein zentraler Server ausgeführt ist und dispositive Zuginformationen
	bereitstellen kann.

Schritt 220:	Der Slave-EVC 106 sendet eine Anfrage
	betreffend die Zugkonfiguration über das
	GSM-R Netzwerk 107 an den Server 108.

Schritt 230:	Der Server 108 stellt Informationen betreffend die Zugkonfiguration sowohl dem Master-EVC 105 als auch dem Slave-EVC 106 bereit.
	Damit ist dem jeweiligen Fahrzeugrechner
	(Master-EVC 105, Slave-EVC 106) bekannt, in
	welchem Schienenfahrzeug er sich befindet
	und welche Kennungen (z.B. Nummern) die
	verbleibenden Fahrzeugrechner dieses Zugs
	haben.

Hierbei sei angemerkt, dass für die Schritte 210 bis 230 noch nicht festgelegt sein muss, welcher Fahrzeugrechner der Master-EVC ist. Hierfür benötigte Informationen können vom Server 108 z.B. vorab den einzelnen Fahrzeugrechnern bereitgestellt werden. Insbesondere ist es ggf. dem Slave-EVC noch nicht bekannt, dass er nicht als Master-EVC agieren soll. Wenn sich ein Fahrzeugrechner als Master-EVC ernennt kann er dies den anderen Fahrzeugrechnern mitteilen, die dann die Rolle der Slave-EVCs annehmen. Beispielsweise kann derjenige Fahrzeugrechner, dessen Führerstand aktiviert wurde, den anderen Fahrzeugrechnern mitteilen, dass er der Master-EVC ist; die Information, wie der die anderen Fahrzeugrechner erreichen kann bzw. welche Fahrzeugrechner in dem Schienenfahrzeug vorhanden sind, hat er (wie auch die anderen Fahrzeugrechner dieses Schienenfahrzeugs) zuvor von dem Server 108 erhalten.
Alternativ ist es möglich, dass auch basierend auf den von dem Server 108 bereitgestellten Daten ermittelbar ist, ob ein Fahrzeugrechner als Master-EVC oder als Slave-EVC agieren soll (z.B. kann sich dies aus der Orientierung eines Zugs in einem Bahnhof und/oder einer Fahrplaninformation ergeben, die dem Server 108 bekannt ist). Beispielsweise kann sich durch die Fahrtrichtung (basierend auf der Fahrplaninformation) des Schienenfahrzeugs und die Position des anfragenden Wagens, der als Triebfahrzeug für die anstehende Fahrt eingesetzt wird, ergeben, dass dieser – auch ohne vorherige Aktivierung durch einen Benutzer – einen aktiven Führerstand zu erwarten hat und daher der darin enthaltene Fahrzeugrechner als Master-EVC agieren soll.
Auch kann derjenige Fahrzeugrechner mit der höchsten oder niedrigsten Identifikationsnummer (sofern jeder Fahrzeugrechner, jede Mobilkommunikationseinheit und/oder jeder Wagen eine eindeutige Identifikationsnummer hat) als Master-EVC von dem Server 108 ernannt werden.
Grundsätzlich gibt es eine Vielzahl von Möglichkeiten, einen Master-EVC zu benennen; hierbei ist lediglich zu beachten, dass die Auswahl zu einem eindeutigen Ergebnis führen sollte, so dass es nur einen einzigen Master-EVC pro Schienenfahrzeug gibt.
Weiterhin ist es möglich, dass mit einer Aktivierung eines Führerstands automatisch der andere Führerstand nicht mehr aktiviert werden kann (verriegelt ist); durch die Aktivierung und die Verriegelung ist es möglich, abzuleiten, welcher Fahrzeugrechner als Master-EVC und welcher als Slave-EVC agieren soll.
Auch kann es sein, dass ein Fahrzeugrechner innerhalb eines Zugverbundes (also nicht an einem der beiden Enden) platziert ist; dies ist ggf. dem Server 108 oder auch dem Fahrzeugrechner dieses Wagens (der auch ein Triebfahrzeug sein kann) bekannt, woraus ggf. der Fahrzeugrechner automatisch eine Rolle als Slave-EVC bestimmt.

Ergänzend sei angemerkt, dass der Server 108 als eine zentrale Einheit oder verteilt in einem Netzwerk, z.B. erreichbar über das Internet, ausgeführt sein kann.

Schritt 240:	Ein Triebfahrzeugführer aktiviert in dem besetzten Führerstand die ETCS-Funktions- und
	Bremsprüfung, diese wird von dem Master-EVC
	105 ausgeführt.

Schritt 250:	Der Master-EVC 105 sendet nach Abschluss der
	eigenen Funktions- und Bremsprüfung eine
	Nachricht (z.B. in Form einer SMS) z.B. als
	ein Kommandotelegramm an den Slave-EVC 106
	zur Aktivierung dessen Funktions- und Bremsprüfung.

Schritt 260:	Der Slave-EVC 106 führt seine Funktions- und
	Bremsprüfung durch.

Schritt 270:	Der Slave-EVC 106 sendet eine Antwort-
	Nachricht (z.B. als SMS) mit dem Ergebnis
	des Prüflaufs (z.B.: erfolgreich, nicht erfolgreich, Ausführung nicht möglich; ggf.
	auch Details bzw. Parameter betreffend den
	Prüflauf selbst oder sonstige Informationen
	(Dauer, Uhrzeit, etc.)) an den Master-EVC
	105.

Der Master-EVC 105 überwacht so die Funktions- und Bremsprüfung für das gesamte Schienenfahrzeug, d.h. steuert z.B. sequentiell die einzelnen Slave-EVCs an. Durch die sequentielle Ansteuerung kann verhindert werden, dass sich gleichzeitige Prüfläufe mehrerer Slave-EVCs gegenseitig beeinflussen. Der Master-EVC hat somit die Kontrolle über die Abfolge der Prüfläufe und kann ggf. auch gleichzeitige Prüfläufe in unterschiedlichen Slave-EVCs veranlassen, wenn z.B. bekannt ist, dass eine Beeinflussung ausgeschlossen werden kann oder wenn die Art der Beeinflussung durch den Master-EVC bekannt oder unkritisch ist bzw. kompensiert werden kann.
Wenn alle bekannten und erreichbaren EVCs getestet wurden, wird von dem Master-EVC dem Triebfahrzeugführer das Testergebnis für alle EVCs angezeigt.
Vorzugsweise erfolgen die Prüfläufe, wenn sich das Schienenfahrzeug im Stillstand befindet. Weiterhin ist es eine Option, dass sich die Slave-EVCs in einem ETCS-Modus "Schlafend" oder "Stand-By" befinden. Die einzelnen EVCs kennen beispielsweise die in dem Zugverband vorhandenen Angaben zu den weiteren Systemen, z.B. Kennungen, Telefonnummern, etc.
Anhand des hier vorgeschlagenen Ansatzes ist es auch möglich, nationale Systeme (STMs/NTCs: länderspezifische Übertragungsmodule (STM), nationale Zugsteuersysteme (NTCs)) anzusteuern und deren Funktionsprüfungen auszulösen, sofern dies gemäß deren Einsatzbedingungen zulässig ist.
Die Lösung ist anwendbar für feste Zugkompositionen, wenn z.B. in den einzelnen Fahrzeugrechnern jeweils die Daten für die Kommunikationsbeziehung (eindeutige Gerätekennung und Telefonnummern) in den Geräteparametrierungen hinterlegt sind; eine Pflege der hinterlegten Daten kann automatisiert z.B. über die Kommunikationsschnittstelle und/oder manuell, z.B. durch Wartungspersonal, erfolgen.
Auch ist der Ansatz verwendbar für variable Schienenfahrzeuge: In diesem Fall kann eine zentrale Verwaltungsinstanz (z.B. in Form des vorstehend erläuterten Servers 108) vorgesehen sein, die die Fahrzeugrechner mit den betrieblichen Zugnummern und den Daten der anderen Fahrzeugrechner versorgt; dies kann automatisiert durch die zentrale Verwaltungsinstanz erfolgen oder die Daten können zu vorgegebenen Zeitpunkten oder Ereignissen von den Fahrzeugrechnern angefragt bzw. aktualisiert werden.
Die Verwaltungsinstanz kann als ein dispositives System mit den betrieblichen Zugkompositionen versorgt werden und die Daten den eingesetzten Fahrzeugrechnern bereitstellen.
Ein beispielhaftes Szenario kann wie folgt ausgeführt sein: Die Fahrzeugrechner melden sich mit ihrer Inbetriebnahme bei dem Server 108 über die Funkverbindung an. Hierbei werden die ETCS-Kennung und die Fahrzeugkennung von jedem Fahrzeugrechner dem zentralen Server gemeldet. Anhand dieser Daten kann der Server prüfen, in welchem Zugverband der einzelne Wagen des Schienenfahrzeugs eingesetzt wird/werden soll. Der Server meldet dann zurück, welche anderen Fahrzeugrechner in diesem Zugverband vorhanden sind und teilt deren Kommunikationsdaten mit. Wird nun ein Fahrzeugrechner zum Master-EVC (z.B. durch Aktivieren des Bedienplatzes – pro Zugverband soll nur ein Bedienplatz aktiv sein), kennt dieser Master-EVC die Daten der Slave-EVCs des Schienenfahrzeugs und kann die Funktions- und Bremsprüfungen veranlassen bzw. koordinieren (z.B. in einer vorgegebenen Sequenz).
Der vorliegende Ansatz hat u.a. den Vorteil, dass beliebige Zugkonfigurationen günstig ausgerüstet werden können und keine aufwendigen Bussysteme zusätzlich installiert werden müssen. Eine gegebenenfalls bereits vorhandene Ausrüstung (vorhandene GSM-R Einheiten für die Kommunikation mit den ETCS-Streckeneinrichtungen) kann für die neue Aufgabe "direkte Kommunikation der Fahrzeugrechner untereinander" genutzt werden.
Die betrieblichen Abläufe (Vorbereitungsdienst) verkürzen sich erheblich, da alle Fahrzeuge von nur einer Person oder automatisiert flexibel und zeitoptimiert geprüft werden können.
Auch wird eine zentrale Koordination der Prüfabläufe ermöglicht, wodurch unerwünschte wechselseitige Beeinflussungen der Prüfabläufe verhindert werden.
Somit wird hiermit auch vorgeschlagen, eine Kommunikation von insbesondere ETCS-fähigen Fahrzeugrechnern, die in unterschiedlichen Wagen eines Schienenfahrzeugs vorhanden sind, über eine mobile Kommunikationsschnittstelle zu koppeln. Hierbei werden vorzugsweise einer der Fahrzeugrechner als Master-Fahrzeugrechner und die anderen Fahrzeugrechner des Schienenfahrzeugs als Slave-Fahrzeugrechner bestimmt. Die Koordination der Kommunikation sowie der Vergabe vorbestimmter Aufgaben, z.B. Funktions- und Bremsprüfungen, veranlasst der Master-Fahrzeugrechner. Hierbei ist es von Vorteil, dass die mobile Kommunikationsschnittstelle, z.B. in Form des GSM-R Netzes oder eines Nachfolgenetzes, genutzt wird, um eine flexible, zeiteffiziente und kostengünstige Möglichkeit zu schaffen, Funktions- und Bremsprüfungen automatisiert an allen in Frage kommenden Stellen des Schienenfahrzeugs durchzuführen.
Obwohl die Erfindung im Detail durch das mindestens eine gezeigte Ausführungsbeispiel näher illustriert und beschrieben wurde, so ist die Erfindung nicht darauf eingeschränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen.
Bezugszeichenliste

101: Schienenfahrzeug
102: Triebfahrzeug
103: Reisewagen
104: Triebfahrzeug
105: Fahrzeugrechner (hier beispielhaft: Master-EVC)
106: Fahrzeugrechner (hier beispielhaft: Slave-EVC)
107: mobiles Kommunikationsnetzwerk (z.B. GSM-R)
108: Server
210–270: Schritte der Kommunikation

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 Nicht-Patentliteratur

http://de.wikipedia.org/wiki/ETCS [0002]

Claims

Wagen (102, 104) zum Einsatz in einem Schienenfahrzeug (101) – mit einem Fahrzeugrechner (105, 106), – wobei anhand des Fahrzeugrechners (105, 106) über eine mobile Kommunikationsschnittstelle (107) Daten an einen Fahrzeugrechner (106) eines anderen Wagens (104, 102) desselben Schienenfahrzeugs (101) übermittelbar sind.
Wagen nach Anspruch 1, bei dem der Fahrzeugrechner die Rolle eines Master-Fahrzeugrechners oder eines Slave-Fahrzeugrechners erhält infolge einer Kommunikation mit einem Server.
Wagen nach Anspruch 2, – bei dem über die mobile Kommunikationsschnittstelle von dem Fahrzeugrechner an den Server eine Anfrage betreffend das Schienenfahrzeug übermittelbar ist und – bei dem der Fahrzeugrechner von dem Server in Folge der Anfrage eine Nachricht betreffend das Schienenfahrzeug erhält.
Wagen nach Anspruch 3, bei dem die Nachricht mindestens eine der folgenden Informationen umfasst: – eine Position des Schienenfahrzeugs, – eine Position des Wagens innerhalb des Schienenfahrzeugs, – eine Zusammensetzung des Schienenfahrzeugs, – weitere Fahrzeugrechner und Kommunikationsdaten der weiteren Fahrzeugrechner des Schienenfahrzeugs.
Wagen nach einem der vorhergehenden Ansprüche, bei dem der Fahrzeugrechner eine ETCS-Funktion bereitstellt.
Wagen nach einem der vorhergehenden Ansprüche, bei dem die an den Fahrzeugrechner des anderen Wagens übermittelten Daten eine Funktions- und/oder Bremsprüfung des anderen Wagens veranlassen.
Wagen nach Anspruch 6, bei dem der Fahrzeugrechner des anderen Wagens nach durchgeführter Funktions- und/oder Bremsprüfung eine Rückmeldung an den Fahrzeugrechner übermittelt.
Wagen nach einem der vorhergehenden Ansprüche, bei dem der Fahrzeugrechner eine Kommunikation mit mehreren anderen Fahrzeugrechnern, die jeweils in einem Wagen des Schienenfahrzeugs angeordnet sind, koordiniert.
Wagen nach einem der vorhergehenden Ansprüche, bei dem der Fahrzeugrechner die Rolle eines Master-Fahrzeugrechners erhält infolge einer Aktivierung eines Führerstands des Wagens.
Wagen nach einem der vorhergehenden Ansprüche, bei dem der Wagen eine der folgenden Komponenten eines Schienenfahrzeugs ist: – eine Lokomotive; – ein Triebwagen mit Antrieb; – ein Triebwagen ohne Antrieb; – ein Reisewagen; – ein Güterwagen.
Schienenfahrzeug mit mehreren Wagen nach einem der Ansprüche 1 bis 10.
Verfahren zur Kommunikation zwischen Wagen (102, 104) eines Schienenfahrzeugs (101), – wobei anhand eines ersten Fahrzeugrechners (105), der in einem ersten Wagen (102) angeordnet ist, über eine mobile Kommunikationsschnittstelle (107) Daten an einen zweiten Fahrzeugrechner (106), der in einem zweiten Wagen (104) desselben Schienenfahrzeugs (101) angeordnet ist, übermittelt werden.
Computerprogrammprodukt, das direkt in einen Speicher eines digitalen Computers ladbar ist, umfassend Programmcodeteile, die dazu geeignet sind, die Schritte des Verfahrens nach Anspruch 12 durchzuführen.
Computerlesbares Speichermedium umfassend von einem Computer ausführbare Anweisungen, die dazu geeignet sind, dass der Computer Schritte des Verfahrens nach Anspruch 12 durchführt.