Version

Current version for Norwegian SIRI profile is: v1.1 (last changed 10 Nov 2020)

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

Links for more information about the formats

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:

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

SIRI also supports real-time information data types which are not included in the Norwegian profile:

Production Timetable (PT) for changes in planned time table data outside the current operational day.
Stop Timetable (ST) changes (theoretic, planned, or calculated) in arrivals and departures for stops outside the current operational day.
Stop Monitoring (SM) arrival- and transfer times for the same operational day.
1. Calculated arrival time for a vehicle, usually based on GPS data.
Connection Timetable (CT) used to inform about guaranteed interchanges outside the current operational day.
Connection Monitoring (CM) for continuous updates on guaranteed interchanges.
1. Whether the guarantee will be upheld.
2. Unplanned interchanges (for example, a bus will wait for a train).
General Messaging (GM) for general text-based information, such as, for example, describing a widely impactful disruption.
Facility Monitoring (FM) for updating the status of equipment, or services.
1. Elevators, escalators, ticket vending machines.

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:

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
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
Usage of data fields
1. Meanings
2. Whether the field is mandatory or not
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".

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.

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.

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 `ISO 8601`, where "00:00" is midnight. 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 / RFC 1766`.
Location	Locations must always be defined according to `WGS84/GML` (normally `EPSG:4326`) 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.

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:

Publish/Subscribe - Direct delivery (asynchronous)
Publish/Subscribe - Fetched delivery (asynchronous)
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.

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.

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

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)

Data types

NaturalLanguageStringStructure

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 ISO 639-3 (recommended) or as a two-letter code according to ISO 639-1 / RFC 1766.

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.

NaturalLanguagePlaceNameStructure

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 ISO 639-3 (recommended) or as a two-letter code according to ISO 639-1 / RFC 1766.

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

FramedVehicleJourneyRefStructure

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

Preface

Introduction

Service Interface for Real Time Information (SIRI)

SIRI high-level model

Services supported by the Norwegian SIRI-standard

What the profile does not include

Terminology

SIRI-specific objects and formats

General requirements on data

Using ID's

Fixed ID's

Exchanging data

Asynchronous

Publish/Subscribe - Direct delivery

Publish/Subscribe - Fetched delivery

Synchronous

Request/response

General requirements

Standard values

Data correctness

Data completeness

Data content

Data freshness

Common components

Message objects

ServiceDelivery

Data types

NaturalLanguageStringStructure

NaturalLanguagePlaceNameStructure

FramedVehicleJourneyRefStructure