Preface

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.

Introduction

Service Interface for Real Time Information (SIRI)

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. 

• Well known interface
  
  • Openness
  • Scalability
  • Flexible for particular needs
• Re-useability for architecture, infrastructure and services (cost-saving)
  • Content independent from transfer protocols
  • Standardised publication and message handling 
    • WebService (HTTP/SOAP with request/response) and WS-PubSub
    • Supports common mechanisms for access control, versioning and error handling
  • Configurable updating and filtering

SIRI high-level model

Overview of the functional services from the official SIRI-documentation:

Services supported by the Norwegian SIRI-standard

Real-time information in Norway is exchanged in three formats, SIRI-ET, SIRI-SX and SIRI-VM:

1. Estimated Timetable (ET) for continuous updates per line, restricted to the current operational day (may differ from calendar days).
   1. Changes like delays, cancellations, additional departures, over-takes, or stops that are not going to be served.
      
      
2. Situation Exchange (SX) for information on disruptions in the public transport service
   1. Information about planned deviations (such as maintenance work on the tracks)
   2. Information about unplanned deviations (such as accidents, unforeseen issues with passengers, objects blocking the road, or severe weather)
      
      
3. Vehicle Monitoring (VM) for tracking the position of the vehicles used for public transport
   1. The actual position of vehicles as they traverse a route (GPS data).

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:

1. Identification of reference data:
   1. Lines, Routes, and VehicleJourneys with arrival- and departure information
   2. StopPlaces, including type and Quays
   3. Connections and Transfers
   4. Data values
      • ServiceCategory
      • ProductCategory
      • VehicleFeatures
2. Specify technical data exchanges
   1. Type of data stream/subscription
   2. Categorisation of messages and data
   3. Message receipts (when relevant)
   4. Filtering mechanisms
   5. Consolidation and forwarding of partner-data (including monitoring)
   6. Meaning of functions
3. Usage of data fields
   1. Meanings
   2. Whether the field is mandatory or not
4.  The ability to describe possible expansions outside the bounds of the main SIRI profile.

What the profile does not include

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:

• User guides
• List of available services
• Access privileges
• Monitoring (uptime, technical disturbances, maintenance)

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.

Terminology

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". 

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.

SIRI-specific objects and formats

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.

General requirements on data

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.

• Values must be trimmed (no blanks first or last in data values)
• Characters must be valid and in accordance with the encoding.

Using ID's

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.

• References to stops must always use ID's from the national stop place registry.
• The data source is responsible for ensuring that ID's are correctly linked between timetable- and real-time data.

Fixed ID's

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.

Exchanging data

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:

1. Publish/Subscribe - Direct delivery (asynchronous)
2. Publish/Subscribe - Fetched delivery (asynchronous)
3. Request/response (synchronous)

Asynchronous

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.

Publish/Subscribe - Direct delivery

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.

Publish/Subscribe - Fetched delivery

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.

Synchronous

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.

Request/response

The service will be designed to deliver data per request, in accordance with the requestors filtering criteria (included in the fetch request).

General requirements

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.

Standard values

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:

• The time interval of fetched data
• Filtering
• Change-before-update

Data correctness

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:

• Data content must comply with requirements stipulated in this profile
• Data should be semantically appropriate and interpretable by consumers
• Even in cases when technically not prohibited, e.g. due to an option between data types, empty data should still not be submitted
• Published real-time information should contain genuine updates of the message content
• Test or dummy data - or other inapplicable data such as placeholders, ficticious values, content out of scope/bounds or for other reasons being without relevant informational value - must not be published in production environments

Data completeness

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.

Data 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.

Data freshness

It is expected that new messages are published as soon as feasible after the source data has been changed. For example:

• Changes in stops (EstimatedCall → RecordedCall)
• Quay to be used has been determined or changed
• Adjustments in estimated arrivals or departures

Common components

This chapter describes the generic concept used for exchanging real-time information in accordance with the Norwegian SIRI profile. 

Message objects

ServiceDelivery

Data types

NaturalLanguageStringStructure

NaturalLanguagePlaceNameStructure

FramedVehicleJourneyRefStructure