Current version for Norwegian SIRI profile is: v1.1 (last changed ) |
A Norwegian standard for exchanging uniform real-time data is extremely valuable for:
Entur AS on behalf of Jernbanedirektoratet
...in order to efficiently collect all real-time data from each data provider, ensure consistency of data, and increase data quality. This allows the creation of multimodal information systems which may be used to implement nationwide journey planning solutions and publicize business neutral information to all interested parties.
for travellers
...in order to present relevant, and up-to-date, high-quality journey suggestions.
for public transport operators
...in order to re-use the data in their own journey planning-, ticketing-, and information systems, and offer a better service to their customers.
for third party service providers
...in order to minimize unnecessary costs related to supporting multiple different exchange formats, and to contribute to continued growth of standardized public transport data exchange.
Service Interface for Real Time Information (SIRI)
is a CEN-specification (CEN/TS 15531, prCEN/TS-OO278181
) for exchanging real-time data for public transport and vehicles. Its development was a cooperative effort between France, Germany (Verband Deutscher Verkehrsunternehmen, VDV), Scandinavia and Great Britain (UK Real Time Interest Group, RTIG
). The standard is based on the reference model Transmodel (CEN TC278, EN12896
) and contains a general model for real-time data and an XML Schema for its implementation.
The SIRI format is used to update planned data with short term changes and deviations in the form of vehicle positions, estimated arrival times, and relevant textual messages.
The guidelines for using SIRI 2.0 XML Schema are specified by a local (Norwegian) profile of the SIRI format, which accounts for existing systems, as well as future needs. Like the Nordic NeTEx Profile, which defines the planned and fixed portion of public transport data, the Norwegian SIRI profile describes how- and which parts of the wider format to use. It is based on Transmodel 5.1 (EN 12896: 2006)
which in turn is based on the standards of NEPTUNE (AFNOR - PR NF P99-506 desember 2009)
and IFOPT (EN 28701 - Identification of Fixed Objects in Public Transport). The purpose of the profile is to clarify which events and data are expected to be included in a comprehensive data exchange and to make the implementation of common standards easier.
SIRI defines a standardised communication layer with procedures and mechanisms for exchanging data by means of a format which is openly described to the public and in wide use around the world.
|
Overview of the functional services from the official SIRI-documentation:
Real-time information in Norway is exchanged in three formats, SIRI-ET, SIRI-SX and SIRI-VM:
SIRI also supports real-time information data types which are not included in the Norwegian profile:
|
What the Norwegian SIRI profile includes
Based on relevant use cases as well as experience from existing real-time systems, the following features have been included:
Technical specifications, local protocols, and their referential implementations are not included in the Norwegian SIRI profile. The same is true for access privileges, the technical details for data transfers, and the administration of data sources and users.
Details regarding the methods of data transfer are however described in separate protocols, established and agreed upon between Entur, data sources and data users. This includes:
More info on utilisation of the Norwegian real-time data feeds, technical examples, real-time API documentation and a complete list of available data streams can be found at https://developer.entur.org/pages-real-time-intro.
Terms and concepts for real-time data in SIRI are, just as in the case of stops- and timetable data, defined according to the NeTEx format standard, based on the European reference model "Transmodel".
For a more detailed description of Transmodel-specific terms, see the Norwegian NeTEx profile. |
Exchanging data in a single format means all communication systems involved need to have a unified interpretation of the terms and concepts being used.
With Transmodel as the source for conceptual names, all objects will have English names, and any use of Norwegian terminology should be considered as guiding only since local concepts often have widely varying historical meanings and associations. For that reason, in particular, all users of the format should strive to use the unified terminology to the furthest extent possible.
It is likewise important to point out that all ID's for stop places (StopPlace, Quay, etc.) in the SIRI data must refer to the official stop ID's found in the national stop place registry. This is important for both data sources- as well as users.
Definitions of Transmodel-related objects can be found in the Norwegian NeTEx profile. The following complementary table defines and clarifies SIRI-specific terms.
Please note that the list is not exhaustive, and the list may be expanded on when needs arise.
Data | Description of data type |
---|---|
Encoding | Primarily UTF-8, but ISO-8859-1 and ASCII can also be handled. |
Date/Time | Dates and times must be in local time, according to Please note that the minimum granularity of times is in seconds, but even more precise timestamps can be used. |
Language | The language used must be defined as a three-letter code according to ISO 639-3 (recommended) or as a two-letter code according to ISO 639-1 . |
Location | Locations must always be defined according to Coordinates in other formats must be converted to WGS84 before being published in SIRI. |
StopPoint | In accordance with Transmodel, objects refer to a logical stop point, normally where passengers can board and alight. For practical reasons these points always have to be references to valid stops in the national stop place registry. |
Destination | Usually, the final, or an important intermediary stop place in the route. |
Origin | Usually, the first stop place in the route. |
For real-time data delivered in XML, the structure and content must syntactically be well-formed in accordance with SIRI 2.0 XML Schema (XSD), where all data fields contain meaningful information and are correctly formatted.
Requirements on unique ID's are described with more detail in the Norwegian NeTEx profile. It is important that all ID's in the SIRI- and NeTEx datasets are constants (real-time, stops, timetables), in order to prevent mismatches and other irregularities.
Just as in the case of timetable data, it is strongly recommended that unchanged objects keep their ID's unchanged across datasets. This makes long term referencing, and tracking of changes easier.
Communication of data must be implemented in accordance with the principles of REST-based services via HTTP.
In technical terms, the exchange of data must be identical for all types (SIRI-ET, SIRI-SX and SIRI-VM).
Three forms of data acquisition are allowed:
The service has been designed to continuously deliver data updates to all subscribed consumers.
When establishing a subscription, the data stream must be validated or reported as erroneous through the protocols of the mechanism.
All services of the publish/subscribe type must send heartbeats in accordance with the subscription-request (HeartbeatInterval), to ensure verification of service availability and operational status.
When using Direct Delivery the data is continuously streamed to all subscribers immediately after they are released into the stream. The recipient system is responsible for handling the received messages. A received message is acknowledged with a HTTP 200 "OK" success-response.
When using Fetched Delivery data is only sent when the receiving system has verified that it is ready to receive data from the stream. The message has to remain available with the data source until an explicit dataSupplyRequest has been received, and the system has ensured data delivery in accordance with it. This delivery method allows the receiving system to hold off on data fetches until it is ready to do so. It is the responsibility of the data source to ensure that data is kept until the consumer has fully downloaded it.
Explicit fetching of datasets based on service type, time, and possibly more parameters. When disruptions or other errors occur, the fetch attempt should result in predefined error messages.
The service will be designed to deliver data per request, in accordance with the requestors filtering criteria (included in the fetch request).
It is expected that normal data deliveries will contain updates/changes since the most recent push/request. If new messages also contain previously delivered messages, mechanisms must be implemented in the exchange protocol to prevent duplication or other corrupting issues.
All fields used when setting up a data stream, or when calling the services, are expected to have meaningful values, defaults and to be in accordance with request-parameters. For example:
Data providers must make appropriate effort to ensure that the data is correct and valid, both technically and in the sense that the content is meaningful. For example:
The real-time information builds upon static and planned data as described in the Nordic NeTEx Profile, which the SIRI data is supporting, enriching or replacing. Which is described in detail where relevant throughout this profile document.
However, the real-time data should in itself be be complete and contain all necessary information within the XML file, without depending on content from other SIRI files or external SIRI data streams to provide meaningful content.
The data stream will be delivered in accordance with specified input-parameters (i.e. filtered / reduced accordingly). Likewise, it is expected that when no input-parameters are present, a full dataset is requested.
It is expected that new messages are published as soon as feasible after the source data has been changed. For example:
This chapter describes the generic concept used for exchanging real-time information in accordance with the Norwegian SIRI profile.
Container for SIRI Functional Service delivery Norwegian SIRI profile supports:
|
ServiceDelivery | ||||
---|---|---|---|---|
Name | Type | Cardinality | Description | |
element | ResponseTimestamp | xsd:dateTime | 1: 1 | Time when the dataset was generated/published. |
element | ProducerRef | xsd:NMTOKEN | 1: 1 | Codespace for dataset producer. |
(choice) element | EstimatedTimetableDelivery | EstimatedTimetableDeliveryStructure | 1: 1 | Data element for Estimated Timetable (SIRI-ET), with changes in one or more planned VehicleJourneys within the same operating day. |
SituationExchangeDelivery | SituationExchangeDeliveryStructure | Data element for Situation Exchange (SIRI-SX), with information regarding one or more situations (or updates to previously published situations). | ||
VehicleMonitoringDelivery | VehicleMonitoringDeliveryStructure | Data element for Vehicle Monitoring (SIRI-VM), with monitoring information for one or more VehicleJourneys (for estimated adjustments of time table information) |
Text strings with an assigned language code. |
NaturalLanguageStringStructure | ||||
---|---|---|---|---|
Name | Type | Cardinality | Description | |
attribute | xml:lang | xsd:string | 0: 1 | The language used must be defined as a three-letter code according to Interpreted as the default "NOR" unless otherwise specified. This must be specified when the message language is other than the default. |
element | (element content) | xsd:string (non-empty) | 1: 1 | The message text. |
Text strings with an assigned language code. |
NaturalLanguagePlaceNameStructure | ||||
---|---|---|---|---|
Name | Type | Cardinality | Description | |
attribute | xml:lang | xsd:string | 0: 1 | The language used must be defined as a three-letter code according to Interpreted as the default "NOR" unless otherwise specified. This must be specified when the message language is other than the default. |
element | (element content) | xsd:string (non-empty) | 1: 1 | The message text |
Reference objects for DatedVehicleJourneyRef with a specified DatedFrameRef (date), in order to ensure that VehicleJourney objects with the same ID can be separated based on their dates. |
FramedVehicleJourneyRefStructure | ||||
---|---|---|---|---|
Name | Type | Cardinality | Description | |
element | DataFrameRef | xsd:NMTOKEN | 1: 1 | Date must have the ISO-format (YYY-MM-DD) for the departure in question. Must be in local time. |
element | DatedVehicleJourneyRef | xsd:NMTOKEN | 1: 1 | ID for the related VehicleJourney (must be the same as the ID of the corresponding VehicleJourney in the NeTEx dataset). |