[railML2] Extensions to RailML for Passenger Information within vehicles [message #2533] |
Fri, 11 September 2020 15:40 |
Thomas Kabisch
Messages: 8 Registered: September 2020
|
Junior Member |
|
|
[English text below]
Hallo in das Forum,
zunächst kurz eine Vorstellung zu meiner Person und Hintergrund:
mein Name ist Thomas Kabisch, ich bin beschäftigt im SW-Engineering bei der Stadler Pankow GmbH, dem deutschen Ableger des Schweizer Schienenfahrzeugherstellers Stadler Rail. Stadler ist seit jüngstem mit im Kreis der RailML-Partner dabei.
In unserem Hause wurde in der jüngsten Zeit eine neue SW-Lösung für die Steuerung der Fahrgastinformation im Zug entwickelt. Diese soll künftig als Standardprodukt in neuen Fahrzeuggenerationen verwendet werden.
Dieses OnBoard-System wird grundsätzlich über zwei Datenströme versorgt:
i) einen Offline-Datenstrom für die sogenannte Grunddatenversorgung (z.B. Fahrplandaten) und
ii) einen Online-Datenstrom für aktuelle Ereignisse/Updates, die während der Fahrt auftreten (z.B. Verspätungen von Anschlusszügen).
Für die Grunddatenversorgung (i) unseres Systems wird RailML verwendet. Da bisher die Fahrgastinformation nicht Bestandteil von RailML war, haben wir den Standard 2.4. an einigen Stellen erweitert.
Grundsätzlich liegt der Schwerpunkt auf der Übertragung des Fahrplans, daneben sind einige erweiterte Informationen im Infrastrukturschema (vor allem unterhalb der OCP) vorgenommen wurden.
Neben der Beschreibung der verschiedenen Inhalte für Anzeigen und Ansagen werden deren Auslösebedingungen/Trigger (bspw. grundsätzlich vor einer Station oder spezifisch nur während einer bestimmten Fahrt) und die zu verwendenden Ausgabekanäle (bspw. Ansage auf Außenlautsprechern in Fahrtrichtung rechts) definiert.
Die entsprechende Schnittstellendokumentation des benutzten RailML 2.4 subsets zusammen mit den FIS-spezifischen Erweiterungen finden Sie im verlinkten Dokument:
https:// forum.railML.org/userfiles/2020-06-29_stadler-fahrgastinform ation-zug-railml25.pdf
Die in der RailML-Community bereits laufenden Bestrebungen der Integration von Fahrgastinformation in RailML 2.5 kamen leider für unsere Entwicklung etwas zu spät, aber wir möchten gern unsere Ideen noch mit einbringen, um dann auch unsere Lösung in einem der nächsten Releases auf RailML 2.5 heben zu können.
Dieser Thread soll daher als Diskussionsgrundlage dienen, um die Ideen hier zusammenzubringen.
Hello everybody,
first of all I would like to introduce myself and my background.
My name is Thomas Kabisch, I am part of the software engineering team at Stadler Pankow, the German branch of the Swiss rail manufacturer Stadler Rail. Stadler recently became a RailML partner.
At Stadler, we recently re-implemented the on-board Passenger Information System (PIS) of our trains. The new solution is planned to become the standard-solution for new fleets of Stadler vehicles.
The on-board PIS-System generally utilises two data streams:
i) an offline-data stream that contains the basic dataset (such as timetable information)
ii) an online-data stream for updates and event-driven information during the journey (such as delays of connecting trains).
We utilise RailML for the basic dataset (i). Due to the lack of PIS-structures within the current RailML-standards we extended RailML 2.4 to fulfill our requirements.
The main aim of the RailML- data stream is the definition of the timetable. Also, some infrastructure elements are covered (mainly within OCP).
The data structure should allow to define the PIS-Content (such as announcements or annotations), trigger mechanisms (e.g. execution with respect to stations and/or specific timetables) and output channels (such as a specific group of train loudspeakers).
You will find the specification of the utilised RailML 2.4 subset together with the description of the PIS-specific extensions in the linked document (unfortunately in German only):
https:// forum.railML.org/userfiles/2020-06-29_stadler-fahrgastinform ation-zug-railml25.pdf
Current discussions within the RailML-community that focus on the extension of RailML towards PIS-use cases were a little late for our project schedule. Nevertheless, we would like to integrate our ideas into the upcomming standard RailML 2.5 such that we can utilise the new standard in one of the next releases of our PIS-solution.
This thread should become a discussion base for this issue.
Viele Grüße / Regards,
Thomas Kabisch
|
|
|