Draft:Austria

Overview in the National Level

For many implementations the VDV standards (incl. VDV736) are preferred over other options, for them being tailored to the regional specifics.

MVO publishes NeTEx data and preferably uses VDV736 (SIRI-SX) for situation information.

Use cases

Description

For our purposes of operating and maintaining the customer information channels of Wienerlinien (Wienmobil-App, digital signage & departure boards, Website, On-Board Information, etc.), we have introduced an API-Gateway as a middleware component.

This is to ensure that all information channels presented to the customer source the information from one single system (API-Gateway). Thus, the customer will find homogenous information in all channels available to them.

Architecture

Since the data sources of the API-Gateway may provide different formats or data necessary for ‘customer information’ may be scattered over various independent sources, we have decided to implement SIRI and/or NeTEx as canonical data format within the API-GW.

This allows for easy consolidation of information within the API-GW to ensure the API-GW is the single point of truth for all customer information channels.

The API-GW can provide the customer information channels directly with information in the canonical format (SIRI or NeTEx) or transform the data into any format required by the consuming system.

For certain use cases the data can be enriched before being provided to the customer information channel:

• Automatic translation of SIRI-SX Situation Descriptions
• Generation of sign language video
• Generation of workload or delay estimates based on ML

Use cases

• FIS+: On Board information screens in our latest subway rolling stock (X-Wagen)
  • The necessary information (station departures & current situations) is pulled from the internal data source, transformed to SIRI-SM & SIRI-SX (canonical format), transformed into a proprietary format containing only the most relevant information (super lightweight as the bandwidth is very limited) and forwarded to the rolling stock.

• Wienmobil App & Wienmobil Monitor: The necessary information (station departures & current situations) is pulled from the data sources (incl. external data sources of other transport operators (ÖBB)), transformed to SIRI-SM & SIRI-SX (canonical format), cached within the API-GW & forwarded on demand to the APP Backend (not conforming to standard as we omit some of the redundant overhead)

• E-Paper timetable: The necessary information (station departures & current situations) is pulled from internal data sources, transformed to SIRI-SM & SIRI-SX (canonical format), cached within the API-GW & forwarded on demand to the e-Paper Backend

• Sign language videos: For the generation of sign language videos, the current situations are regularly pulled from internal data sources, transformed to SIRI-SX and forwarded to the API of SignTime. SignTime checks the situation description for new or updated entries and generates a sign language video for each situation. A Weblink to the video is returned and the API-GW can add this link as custom fields to any further SIRI-SX messages.

• Wienmobil Alexa Skill: The necessary information (station departures) is pulled from the data sources (incl. external data sources of other transport operators (ÖBB) ), transformed into SIRI-SM (canonical format), cached within the API-GW & forwarded on demand to the Backend System of the Alexa Skill

Outcome

• Very well thought out data standard framework -> Any Use Case is possible.
  • This comes at the cost of high complexity, for some colleagues and implementors this is quite challenging.
  • Perfect as canonical data format for that reason.
• We are ready to tackle EU DV 2017/1926.