Guidance

Technical guidance: SIRI-VM

Published 21 October 2020

Introduction

Background and purpose

Passengers need multi-modal travel information that is accurate, timely and complete.

For passengers, real-time information is the most powerful. It allows for in-the-moment journey planning using actual bus locations, rather than expected locations. It enables passengers to understand when the next bus is arriving – rather than when the next bus should be arriving – minimising the time spent waiting for transport.

Moreover, this data can be used for analysis covering:

• punctuality
• congestion
• urban planning
• actual emissions

This guidance is aimed principally at system architects and designers. As well as SIRI (CEN EN15531), the reader will benefit from a basic understanding of other UK and CEN public transport data standards such as Transmodel (EN 12986), NeTEx (CEN TS16614), NaPTAN, and TransXChange.

It does not consider the business processes needed to support the provision of live location information; rather it focuses on the technical implementation of SIRI-VM (Service Interface for Real-time Information Vehicle Monitoring) in the context of the Department for Transport and the Bus Open Data project.

Sources and acknowledgements

The structure and basis of this guidance have been taken from the official CEN SIRI-VM documentation; see SIRI standards family for more detail.

The Department for Transport is grateful to:

• KPMG and ITO World for the initial drafting of the profile
• members of the RTIG for contributing to the construction and validation of this guidance
• stakeholders across the industry who have informed the development of the SIRI-VM profile for the Bus Open Data Service

This guidance provides an insight into the parts of the SIRI-VM standard that will be captured via the Bus Open Data Service. The profile will be reviewed periodically to ensure it is fit for purpose.

If there are any comments or feedback arising from the use of the SIRI-VM profile, please contact us at busopendatasupport@dft.gov.uk.

The SIRI-VM standard

The SIRI standards family

The Service Interface for Real-time Information (SIRI) specifies a European interface standard for exchanging information about the planned, current or projected performance of real-time public transport operations between different computer systems.

SIRI comprises a carefully modularised set of discrete functional services for operating public transport information systems. SIRI supports a range of information exchange services covering:

• planned and real-time timetable exchange
• vehicle activity at stops
• vehicle movement
• information to assist in the provision of reliable connections between vehicles

SIRI is published in five parts. Parts 1 to 3 were first adopted by CEN in 2006 and have since been considerably reworked and revised; parts 4 and 5 came later in 2010.

The published SIRI standards are copyrighted to CEN and available, at a cost, through national standards bodies such as the British Standards Institute. A lot of information – including draft revisions and a free-to-access XSD file – are, however, available in English through github. An informal UK site is also available at www.siri.org.uk.

SIRI is built on other standards in line with normal CEN practice. The base standard is Transmodel and SIRI can be viewed as an implementation of part of Transmodel for the specific purposes of real-time information exchange. Also, SIRI evolved from several national standards, notably VDV454, VDV453, Trident and the draft RTIGXML (which it has superseded).

Figure 1: SIRI functional services

Role of SIRI-VM

The SIRI-VM standard is the vehicle monitoring service, which allows for the exchange of real-time positions of public transport vehicles.

The service is designed to exchange vehicle monitoring information between control systems, and for this information to be distributed to journey planners, alert systems and displays that wish to process and match real-time positions based on structured elements.

While SIRI-VM is created as a business to business (B2B) protocol, it should be assumed that any textual information it contains will be displayed to end-users both through personal devices and public screens at stops and stations. This then demands care in the authoring of text that will be exchanged using SIRI-VM.

SIRI-VM provides information about the current location and expected activities of a particular vehicle. It can detail:

• current and subsequent journeys
• calling points on each journey
• scheduled and expected arrival times

It is widely implemented and has been refined over time to reflect lessons from implementation projects as well as emerging requirements from the industry. The result of this work is that it can be regarded as a robust standard with sufficient knowledge within the industry to ensure new implementations are generally trouble-free.

The use of SIRI-VM rather than one of the other SIRI services will enable greater innovation and a wider range of consumer services to be provided than would be possible if other SIRI services had been selected.

The Bus Open Data Service

Bus location data

The Bus Open Data Service (BODS) enables operators to openly publish their bus location data to the service. This includes real-time data about the vehicle’s position, which is open to all and hosted by BODS.

This supports real-time innovations and use cases such as improved accuracy for journey planning apps, and emissions analysis on real bus journeys.

Real-time information

Bus operators register feeds to BODS, which are subscribed to and consumed by the service, and subsequently published by the Department for Transport.

The service accepts incremental updates of vehicle positions as per the SIRI specification.

The service is operating via the subscription mechanism defined in the SIRI specification and will aim to receive and consume SIRI-VM vehicle position updates at the frequency with which they are sent to the service.

The feed must supply updated data every 30 seconds minimum with higher frequencies (such as every 15 seconds) accepted. If the vehicle position has not changed, the feed must still update at least every 30 seconds to reflect the updated RecordedAtTime.

Data is also made available via BODS to other open data users who wish to use it, including:

• operators
• local authorities
• data aggregators
• third-party application developers

The intended scope of the data includes service delivery, vehicle monitoring delivery, vehicle activity and monitored vehicle journey elements.

Allowing BODS’ IP addresses and ports

To ensure BODS is able to subscribe to an operator’s feeds, the operator and their chosen technology supplier must add BODS servers’ internet protocol (IP) addresses and ports to their ‘allow’ list. These are provided when a data publisher uploads an automatic vehicle location (AVL) feed through BODS.

More detail on this is covered in our BODS implementation guide.

Heartbeat

The service expects a ‘heartbeat’ to be sent every 30 seconds to confirm the operator’s SIRI server is functioning. After multiple successive heartbeats are missed, the service will attempt to re-subscribe periodically until the SIRI-VM feed is resumed.

‘Check status’ request and response

The operator must be able to provide a ’check status’ request and a ‘check status’ response.

Consumer rate limit

The live vehicle data for all BODS operators is available to data consumers on a request/response basis as a single centralised response for all vehicles available. The response is compliant with the SIRI schema in this documentation.

The consumer can either request a filtered subset of data using the BODS application programming interface (API) or a national .zip of all data no more than every 5 seconds from the BODS platform.

It is important to note that consumers do not need to manage many different individual feeds to obtain vehicle data because the BODS service consumes and centralises this data to a single endpoint on behalf of the data consumer.

SIRI-VM profile

A SIRI-VM profile has been developed to support the Bus Open Data Service.

This profile fits within the general CEN SIRI-VM schema, which describes the rules for the XML document being used. The SIRI-VM schema covers the complete breadth of capability of SIRI-VM and is designed to be used in a many different workflows and to support different levels of detail in the data exchanged.

The profile describes the specific parts of the XML schema to be used in a particular implementation and includes which elements and attributes are mandatory in the exchanged data.

The supplied API feed will be validated against the Department for Transport SIRI-VM 2.0 (Q) Profile. Mandatory and optional elements contained within the profile will be captured and supplied to data consumers. Elements within the schema but outside the profile will not be captured by the service.

See Using the Department for Transport SIRI-VM profile for more information.

Time synchronisation and accuracy

To ensure the accuracy of data supplied and the ability to use the location data to provide high-quality information to customers, all equipment and services in the data chain must know the time accurately.

To achieve this, all components that are included in the production and processing of SIRI data should be regularly synchronised with an accurate time service. This could be, for example, using a global positioning system (GPS) for a ticket machine or tracking device and a reliable internet time service for servers.

All timestamps are stated in UTC (Coordinated Universal Time). The use of UTC avoids problems with the changeover to and from British Summer Time.

It is recommended that time is synchronised at least once per day to ensure time is known to a 1 second accuracy.

Using the Department for Transport SIRI-VM Profile

The Department for Transport profile prescribes that certain elements must be populated in a certain way, to ensure data can be cross-referenced with other data sources.

How BODS would like operators to populate certain elements

The following elements should be populated as follows:

Elements	Expected input
ProducerRef	Participant reference that identifies producer of data. Where a message is being passed through from a third-party system then the ProducerRef shall be the ProducerRef of the originating system; if the message has been created within the ProducerRef system then ProducerRef and ParticipantRef shall be the same.
OriginRef	The identifier of the origin of the journey; used to help identify the VEHICLE JOURNEY on arrival boards. This shall be a valid ATCOCode from the NaPTAN database, and same as the ID to the corresponding object in the timetables data.
DestinationRef	The identifier of the destination of the journey; used to help identify the VEHICLE to the public. This shall be a valid ATCOCode from the NaPTAN database, and same as the ID to the corresponding object in the timetables data.
OperatorRef	This shall be the operator’s National Operator Code (NOC) from the Traveline NOC database and same as the ID to the corresponding object in the timetables data.
BlockRef	BLOCK that VEHICLE is running. If this has also been provided in the timetables data, the input should be the same ID as the corresponding object in the timetables data.
VehicleJourneyRef	Reference to the VEHICLE JOURNEY. This shall be the same as the corresponding object in the timetables data and should be a globally unique identifier.
VehicleRef	A reference to the specific VEHICLE making a journey. Must be consistent through the day within the SIRI-VM data. If this is also being provided in the timetables data, the input should be the same ID as the corresponding object in the timetables data.
LineRef	Name or number by which the LINE is known to the public. This shall be the same as the corresponding object in the timetables data provided to BODS.

The SIRI-VM profile’s mandatory and optional elements

Mandatory:

• Bearing
• BlockRef
• DestinationRef
• DirectionRef
• LineRef
• Monitored-VehicleJourney
• OperatorRef
• OriginName
• OriginRef
• ProducerRef
• PublishedLineName
• RecordedAtTime
• ResponseTimestamp
• ValidUntilTime
• VehicleJourneyRef
• VehicleLocation (Longitude, Latitude)
• VehicleMonitoringDelivery (Vehicle Activity)

Optional:

• Departure Boarding Activity
• DestinationAimedArrivalTime
• DestinationName
• ItemIdentifier
• MonitoredCall (Departure Boarding Activity)
• Occupancy
• OriginAimedDepartureTime
• VehicleActivity
• Velocity

Schema interpretation and advice

It is not always desirable or possible to encode every possible scenario or interpretation within a schema and its official standards documentation.

This guidance is a presentation of the SIRI schema as it is applied in the Bus Open Data Service. It contains all the elements necessary for its understanding; however, it does not offer a rewrite or translation of all the SIRI normative documents.

The reader should therefore refer to the standard when necessary, in particular at the technical level, before considering any implementation of SIRI.

All the terminology used in this guidance is that of SIRI, and consequently of Transmodel version 5.1. The reader should therefore refer to the Transmodel standard if clarification of the underlying terminology and data concepts or models is needed.

A set of normative documents underlies the concepts described in this guidance: SIRI: Service Interface for Real-time information relating to public transport operations (BSI EN 15531-1:2015)

• Part 1: Context and framework
• Part 2: Communications infrastructure
• Part 3: Functional service interfaces

National impact and implications

Through the use of the SIRI-VM profile in the Bus Open Data Service operated by the Department for Transport in England, the SIRI-VM profile becomes the English national standard.

Across transport authorities, suppliers and operators’ different implementations, interpretations of the SIRI schema are different from the Bus Open Data Service profile described in this guidance. These remain valid interpretations for the use cases they were designed to address.

t is envisaged that the mandatory elements in the BODS profile will over time form the basis for future more local implementations where the use case requires it.

The long-term implications require appropriate independent consideration; as a result, RTIG has been involved in this work in its role as an independent body.

SIRI-VM elements and attributes

As mentioned previously, the structure and basis have been taken from the CEN SIRI-VM documentation BS EN 15531 parts 1 to 3.

For simplicity, the full SIRI schema profile is not described here – just the SIRI-VM specific elements that are addressed by the profile.

VehicleMonitoringDelivery

The VehicleMonitoringDelivery returns the position of a VEHICLE or group of VEHICLEs.

One or more VehicleMonitoringDelivery elements may be returned as part of a SIRI ServiceDelivery, with a common ResponseTimestamp.

ServiceDelivery / VehicleMonitoringDelivery — Attributes

ServiceDelivery			+Structure
Log	ResponseTimestamp	1:1	xsd:dateTime	Time individual response element was created
Endpoint properties	ProducerRef	1:1	Participant-Code	Participant reference that identifies producer of data. Where a message is being passed through from a 3rd party system then the ProducerRef shall be the ProducerRef of the originating system, if the message has been created within the ProducerRef system then ProducerRef and ParticipantRef shall be the same.
Payload	VehicleMonitoringDelivery	1:*	+Structure	See VehicleMonitoringDelivery element.

VehicleMonitoringDelivery — Element

A VehicleMonitoringDelivery is made up of one or many VehicleActivity elements, each representing a moving VEHICLE following a MONITORED VEHICLE JOURNEY, and indicating its progress relative to the operational schedule. The level of detail included for each VehicleActivity element may vary by implementation and by request.

Each VehicleActivity included in the response has its own identifier, issued by the producer: this can be used to reference previously issued VehicleActivity instances when sending incremental updates.

VehicleMonitoringDelivery — Attributes

VehicleMonitoringDelivery			+Structure
Payload	VehicleActivity	1:*	Describes the progress of a one or more of VEHICLEs along its route.

VehicleActivity — Element

Each VehicleActivity describes the position and relative progress a VEHICLE making a monitored VEHICLE JOURNEY, including scheduled and/or predicted real-time times as follows:

VehicleActivity — Attributes

VehicleActivity			+Structure	Describes the progress of a single VEHICLE along its route.
Log	RecordedAtTime	1:1	xsd:dateTime	Time at which VEHICLE data was recorded.
Currency	ValidUntilTime	1:1	xsd:dateTime	Time until which data is valid.
Identity	ItemIdentifier	0:1	ItemIdentifier	Unique identifier of item within data horizon of producer. Can be used for server-side cleardown of previous Item instances.
Journey-Info	Monitored-VehicleJourney	1:1	MonitoredVehicle-Journey Structure	Provides real-time information about the MONITORED VEHICLE JOURNEY which this VEHICLE is running.

VehicleActivity / MonitoredVehicleJourney — Element

The MonitoredVehicleJourney has the same structure as for MonitoredStopVisit / Monitored- VehicleJourney: whereas for a Stop Visit all calls are relative to the stop, for a VehicleActivity, all calls are relative to the VEHICLE’s current position. Some elements will not be populated in the normal level of detail. The elements that will normally be returned for a VehicleActivity are as follows:

VehicleActivity / MonitoredVehicleJourney — Attributes

MonitoredVehicleJourney			+Structure	DetailLevel: minimum
VehicleJourney-Identity	LineRef	1:1	LineCode	Identifier of line data participant is allowed to access. ID to the corresponding object in the timetable data provided to BODS.
	DirectionRef	1:1	DirectionCode	Direction of the trip (for example INBOUND/OUTBOUND). This must be the same direction as the corresponding object in the timetables data.
JourneyPatternInfo	PublishedLineName	1:1	NLString	Name or number by which the LINE is known to the public. This must be the same ID as the corresponding object in the timetables data in BODS.
ServiceInfoGroup	OperatorRef	1:1	OperatorCode	Operator of journey. This shall be the operator’s National Operator Code (NOC) from the Traveline NOC database and same as the ID to the corresponding object in the timetables data.
VehicleJourneyInfo	OriginRef	1:1	JourneyPlaceCode	The identifier of the origin of the journey; used to help identify the VEHICLE JOURNEY on arrival boards. This shall be a valid ATCOCode from the NaPTAN database, and same as the ID to the corresponding object in the timetables data.
	OriginName	1:1	NLString	The name of the origin of the journey; used to help identify the VEHICLE to the public. This shall be the same as the corresponding object in the timetables data.
	DestinationRef	1:1	JourneyPlaceCode	The identifier of the destination of the journey; used to help identify the VEHICLE to the public. This shall be a valid ATCOCode from the NaPTAN database, and same as the ID to the corresponding object in the timetables data.
	DestinationName	0:1	NLString	The name of the destination of the journey; used to help identify the VEHICLE to the public. This shall be the same as the corresponding object in the timetables data.
	OriginAimedDepartureTime	0:1	xsd:dateTime	Timetabled departure time of VEHICLE from Origin. This shall be the same as the corresponding object in the timetables data.
	DestinationAimedArrivalTime	0:1	xsd:dateTime	Timetabled arrival time of VEHICLE at Destination. This shall be the same as the corresponding object in the timetables data.
JourneyProgressInfo	VehicleLocation	1:1	LocationStructure	Current location of VEHICLE. Measured to front of bus.
	Bearing	1:1	AbsoluteBearingType	Bearing in degrees in which VEHICLE is heading.
	Velocity	0:1	VelocityType	Velocity of vehicle in specified units. Either actual speed or average speed may be used. Default units are metres per second.
	Occupancy	0:1	OccupancyEnum	How full VEHICLE is. Enumeration. If omitted, not known. full | standingAvailable | seatsAvailable
OperationalBlockGroup	BlockRef	1:1	BlockCode	BLOCK that VEHICLE is running. If this is also being provided in the timetables data, the input should be the same ID as the corresponding object in the timetables data.
OperationalInfoGroup	VehicleJourneyRef	1:1	VehicleJourneyCode	Reference to the VEHICLE JOURNEY. This shall be the same as the corresponding object in the timetables data and should be a globally unique identifier.
	VehicleRef	1:1	VehicleCode	A reference to the specific VEHICLE making a journey. Must be consistent through the day within the SIRI-VM data. If this is also being provided in the timetables data, the input should be the same ID as the corresponding object in the timetables data.
CallingPattern	MonitoredCall	0:1	Monitored Call Structure	Describes a call to the VEHICLESs most recently visited stops.

Location

LocationStructure		1:1	+Structure	Geospatial location
Coordinates	Longitude	1:1	LongitudeType	Longitude from Greenwich Meridian. 180° (East) to +180° (West). Decimal degrees. e.g. 2.356
	Latitude	1:1	LatitudeType	Latitude from equator. -90° (South) to +90° (North). Decimal degrees. e.g. 56.356.

MonitoredCall

MonitoredCall			+Structure	Elements relating to departure status
Departure Status	Departure Boarding Activity	0:1	Departure-Boarding Activity Enum	Type of boarding activity allowed at stop. Default is ‘boarding’. boarding | noBoarding | passthru

Sample SIRI-VM data