| [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
|
|
|
|
| Re: [railML2] Extensions to RailML for Passenger Information within vehicles [message #2536 is a reply to message #2533] |
Mon, 14 September 2020 12:46  |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Hallo Thomas Kabisch,
willkommen im Forum und danke für die Vorstellung und das Einbringen.
> Da bisher die Fahrgastinformation nicht
> Bestandteil von RailML war, haben wir den Standard 2.4. an
> einigen Stellen erweitert.
Das ist so nicht ganz zutreffend. Fahrgastinformation war von Anfang an ein (Mit-)Grund der Umstellung von railML 1 auf 2 und läuft bereits seit vielen Jahren mit railML 2.x in verschiedenen Software-Kombinationen. Es ist einer der wichtigsten Anwendungsfälle von <railML><timetable>.
Bei der Einbringung der Erweiterungen von Stadler müssen wir daher aufpassen, dass bereits funktionierender Datenaustausch dadurch nicht überdeckt wird (keine neuen Redundanzen entstehen). Wenn gewünscht, können wir uns Ihr Schnittstellendokument der Erweiterungen dahingehend gern einmal ansehen.
Viele Grüße,
Dirk Bräuer,
leitender Entwickler iRFP, Gründungsmitglied der railML-Initiative.
---
Am 11.09.2020 um 15:40 schrieb Thomas Kabisch:
> [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-fahrga stinformation-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-fahrga stinformation-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
>
>
|
|
|
|
Members
Search
Help
Login
Home
