G03- Backoffice systems

interoperability Guidelines Release G03-2015V1.0

This document defines the detailed guidelines of ITxPT Backoffice systems interoperability.

G03-2015V1 Backoffice systems interoperability Guidelines 2/14

Content

1 GUIDELINES FOR BACKOFFICE INTEROPERABILITY ............................................................... 3 1.1 Public Transport integration scope ........................................................................................... 4 1.2 Ensuring consistent background data across involved systems .............................................. 4 1.3 Ensuring consistent real-time information across involved systems ........................................ 5 1.4 Ensuring consistent disruption and deviation information across involved systems ................ 6 1.5 Protect competitiveness between operators ............................................................................. 7 1.6 Conclusion ................................................................................................................................ 7

2 THE ITxPT BACKOFFICE IT ARCHITECTURE .............................................................................. 8 2.1 Usability across differing organisation structures ..................................................................... 8 2.2 Multi-AVMS coordination........................................................................................................... 8 2.3 Generic Back-office architecture ............................................................................................... 8

3 ITxPT COMPLIANCE LEVELS DEFINITIONS .............................................................................. 10 3.1 Basic ITxPT compliance.......................................................................................................... 10

ORGANISATIONAL ........................................................................................................... 10 SYSTEMS AND SERVICES .............................................................................................. 10 BACKGROUND DATA ...................................................................................................... 10 NETWORK ........................................................................................................................ 11

3.2 Medium ITxPT compliance...................................................................................................... 11 SYSTEMS AND SERVICES .............................................................................................. 11

3.2.1.1 Background data ........................................................................................................ 11 3.2.1.2 Real-time information................................................................................................. 12

3.3 High ITxPT compliance ........................................................................................................... 12 SYSTEMS AND SERVICES .............................................................................................. 12

3.3.1.1 Background data ........................................................................................................ 12 3.3.1.2 Real-time information................................................................................................. 12 3.3.1.3 Disruption and deviation information ......................................................................... 12

4 APPLYING ITS DIRECTIVE 2010/40/EU ...................................................................................... 14

G03-2015V1 Backoffice systems interoperability Guidelines 3/14

1 GUIDELINES FOR BACKOFFICE INTEROPERABILITY

Why do we need back-office interoperability in Public Transport? The ultimate reason is to support the

higher goals that will increase the share of travelling that is conducted using public transport.

The EU Commission has in the ITS Directive suggested bringing ITS deployment into a new era with the

following principles:

Integrated and Interoperable systems

Seamless transport services

Compatibility, interoperability and continuity of ITS solutions across Europe.

Figure 1 - Travelling in a region often means using different operators for different parts of the trip

This has implications on the PTA and the operators working in a region. A PTA should strive to present and

correlate all Public Transport in the region. This should ideally cover both commercial and publicly financed

services.

Harmonized and consistent information should be available so that the public can travel seamlessly in the

region. This includes aspects such as finding travel possibilities, getting relevant real-time and disturbance

information and being able to make interchanges across different transport modes and operators.

In addition to passenger information another important use of the combined data is to ensure good

interoperability and performance of the public transport at a larger scale across different operator.

At the same time the solutions needs to be cost-efficient and respect the competitiveness of the different

operators and system providers involved.

This booklet intends to describe how to use the ITxPT approach for back office interoperability to help

accomplish this; while at the same time take into consideration the different ways public transport is

organized across Europe and the way publicly and commercially financed actors in the area are operating.

G03-2015V1 Backoffice systems interoperability Guidelines 4/14

1.1 Public Transport integration scope

In the most general view of ITxPT, the following possibilities are considered concerning the scope of

geographical PT integration:

Existence of several Public Transport Authorities (PTAs) / Regions.

Existence of a National Organization Unit coordinating the different regions, which could also be the

PTA for one or more of the regions.

Existence of several Public Transport Operators (PTOs) operating in each region.

Existence of PTOs which operate services in more than one region.

Existence of PT Services across regions; i.e. a bus line starting at one region and ending at another

region.

Existence of PTOs in one region who lease or share vehicles with PTOs in another region.

For the purpose of this document, we consider a geographical scope with a single PTA/Region where PT

services are operated by several PTOs.

1.2 Ensuring consistent background data across involved systems

Maintenance and provision of spatial data is fundamental. It is important that the different parties involved in

a region share a common understanding of how to name and refer to different stations, bus stops and other

network objects. In a similar manner there must be a shared understanding on the identification of lines,

especially for connection protection purposes.

The next layer of background data is the temporal data describing the planned timetables of the different

operators.

It must be decided how the responsibility to maintain different types of background data is divided among

the different actors in the region.

It must be clarified how this information is made available to all interested parties in a uniform and

consistent format.

The ITxPT approach for back office applications suggests that Transmodel based standards should be used

to transfer this type of information from the different background data sources to a central hub (integrator).

This means that the responsibility to maintain background data can be decentralized to different

organisations using different types and makes of technical systems. The main requirement is that the

results can be exported through the appropriate exchange protocols and that the common set of stop and

line identifiers are used in all data exchanges.

The assembled information in the integrator can be extracted by any interested party, again using

Transmodel based standards for data exchange.

There are thus two types of data exchanges:

1. Transfer of background data from a party responsible for maintaining a certain part and aspect of

the public transport to a central integrator system. There can be one or many different parties

providing background data in parallel.

G03-2015V1 Backoffice systems interoperability Guidelines 5/14

Figure 2 - Collecting data from many background data sources

2. Transfer of all or selected portions of the combined and harmonized information from the central

integrator to interested parties.

Figure 3- Providing combined and consistent information to multiple consuming systems

1.3 Ensuring consistent real-time information across involved systems

There are typically many different technical systems of different age and make that are used by the different

operators and transport modes in a region to keep track of the real-time movements of the different public

transport vehicles. Often these systems are referred to as automatic vehicle monitoring systems (AVMS).

Some systems collect their information utilising GPS and odometers on board vehicles while others use

wayside equipment to monitor the movements. Sometimes these systems do not have passenger

information as the main focus, but are primarily used to support the operation control.

There is also a term ITCS that is sometimes used as a synonym to AVMS. AVMS is in this document mainly

seen as a source for real-time information from a certain part of the PT operation. This could also be true for

an ITCS, but using the term ITCS also implies that it could cover a larger part or all of the PT operation

including different transport modes.in a city or region.

Regardless of how the different vehicle fleets are monitored there is a need to provide consistent and

harmonized real-time passenger information across the complete public transport operation.

G03-2015V1 Backoffice systems interoperability Guidelines 6/14

The ITxPT approach for back office applications suggests that Transmodel based standards should be used

to transfer real time information of the vehicles movements from the respective AVMS sources to a central

hub (integrator) where the information is harmonized and made available in a consistent format for further

processing.

Real-time vehicle monitoring information can be delivered in parallel from different organisations using

different types and makes of technical systems. The main requirement is that the real-time movements of

the vehicles working public transport services can be exported through the appropriate exchange protocols

and that the common set of stop, line and journey identifiers are used in all data exchanges.

The central hub should provide the assembled information to any interested party, again using Transmodel

based standards for data exchange. At this end there could be different types of dynamic passenger

information systems providing departure and arrival information at platforms, on the web or in apps, The

information could be adapted to passengers at stops or onboard as well those planning to travel shortly.

Figure 4 Harmonized and consistent information made possible through Transmodel based interfaces

1.4 Ensuring consistent disruption and deviation information across involved

systems

Sometimes the operation is not running according to the original plan and short term changes goes into

effect. Examples include individual buses being cancelled or rerouted or major problems such as power

outages that affect track-based operation etcetera. By providing passengers with information of such

deviations and disruptions they get a chance to act accordingly. The scope of such information may apply

across multiple operators. At the same time the information needs to be restricted to those affected to avoid

information overload.

A PTA may provide messages that should be displayed to the public or driver on-board vehicles of different

modes that operate certain lines or pass certain stops.

Sometimes it is the PTO that is responsible to provide disturbance information for the lines it operates.

Often there are combinations where both operators and authorities have partial responsibility for the

deviation and disturbance information. To assure efficient information it may be necessary to coordinate

information before publishing it to the public.

G03-2015V1 Backoffice systems interoperability Guidelines 7/14

The ITxPT approach for back office applications suggests that multiple parallel providers of short term

changes and disturbance information are possible and that Transmodel based standards should be used to

transfer deviation and disturbance information from the different sources to a central hub (integrator).

The central hub should then apply the information to relevant journeys and stops and provide the

assembled information to any interested party, again using Transmodel based standards for data exchange.

One possibility is to use the Transmodel based (CEN/TS 00278181) SIRI VM or SIRI ET exchange

protocols to report vehicle realtime movements from the respective AVMS to the central hub, and use SIRI

SM and SIRI SX to provide information to DPI-systems from the central hub.

1.5 Protect competitiveness between operators

The ITxPT approach for back office applications does not mean that all aspects of information need to be

assembled centrally. It could be important for an operator to keep information concerning vehicle and man

planning secure from competitors for commercial reasons. This implies that it should not be mandatory to

send such information to the integrator, and that exchange protocols should avoid any unnecessary

dependencies on such data. Information concerning fleet management, vehicle scheduling (Blocks), vehicle

maintenance, man scheduling (Duties) and man management are example of aspects that could be kept

within the respective operator’s scope.

1.6 Conclusion

Passenger information should be consistent regardless of the source of information; hence there is a need

for coordinated passenger information at a regional level. It is possible to either manage DPI media on a

regional level or in each local AVMS, or possibly a mix.

However, in order to embrace DPI at regional level, the recommendation is to have systems where:

AVMS and DPI are distinct applications

All information is integrated in a regional hub.

The regional hub is fed by producer systems as AVMS; specific control centres etc, and is used by

information systems which manage the presentation of information for their driven media / device.

From an Integrator perspective, where one wants consistent coordinated information in all media, it is

recommended that the source of data always is the central hub, regardless if the DPI-system resides in the

local AVMS or not, and if the data is produced in the same AVMS or not.

G03-2015V1 Backoffice systems interoperability Guidelines 8/14

2 THE ITxPT BACKOFFICE IT ARCHITECTURE

2.1 Usability across differing organisation structures

The challenge is to propose a back-office IT architecture which is able to adapt to the great variety of

organization architecture.

Different organisation configurations could exist depending on the roles of the actors in transportation and

depending on the geographical organization. For instance:

National Organization Unit could have the Public Transport Authority role

On a national scale there could be several Public Transport Authorities in the same architecture

Public Transport Authority could operate vehicles without operator or use subcontractor to operate

vehicles

Furthermore operator could also use subcontractor operators.

A PTA may coordinate several operators on one area, while one operator may work for several PTA.

In fact the organization configurations are multiple and could evolve over time.

On the application level, there are also different possible architectures.

E.g. DPI on vehicles and stop signs may be managed by operators or the PTA, while DPI on strategic hubs

or websites can be managed by an area coordinator.

2.2 Multi-AVMS coordination

Public transportation systems deal with equipment which can be controlled at different levels:

Vehicle operator level: for instance bus, AVMS

PTA level: for instance stop signs, DPI displays in bus hubs, internet website…

Client level: personal devices like cell phone...

All these different systems will have to exchange data in order to assure consistent information.

Furthermore, when several operators work on the same area, there is often a need to coordinate their

actions, in order to:

Plan operations (for instance establish coordinated timetables)

Manage coordinated operations (for instance connection protection)

Provide coordinated data provision for DPI and AVMS.

In some regions, the PTA is in charge of AVMS coordination through an AVMS integrator, which will gather

all AVMS data and will then dispatch appropriate information to each local AVMS and DPI system.

2.3 Generic Back-office architecture

The ITxPT requirements concerning the back-office system architecture are described in document S03-

Backoffice Architecture specifications. Also, the main concepts concerning information integration are

explained in ITxPT Overview. An example of a generic Back-office architecture with focus on a regional DPI

system is shown in the next diagram.

G03-2015V1 Backoffice systems interoperability Guidelines 9/14

Figure 5 - Back-office architecture with focus on a regional DPI

If the PTA would like to harmonize and centralize all data relevant for passenger information; this will be

done in a PTA Back-office application which in ITxPT is called Integrator.

The Integrator application is a data consumer for all relevant data sources, and it is a data provider for the

DPI applications which implement the DPI services. In a centralized architecture as this, there is a single

Integrator application.

G03-2015V1 Backoffice systems interoperability Guidelines 10/14

3 ITxPT COMPLIANCE LEVELS DEFINITIONS

In the following three chapters three distinct levels of ITxPT compliance are defined. They can be used as a

general guide of possible steps to establish an increasingly harmonized and interoperable system.

3.1 Basic ITxPT compliance

ORGANISATIONAL

There is a common understanding between involved parties how the responsibility for maintaining

background data is divided in the region.

The different parties involved in a region share a common understanding of how to name and refer to

different stations, bus stops and lines uniquely.

SYSTEMS AND SERVICES

Trying to establish efficient information sharing between different transport systems operating in a region,

such as different AVMS, can be very difficult to achieve if the involved systems are not prepared for

exchanging information. For this reason requirements should be placed before the systems are put in place

to prepare for future information sharing.

Consequently, the focus of this basic compliance level are those requirements that should be considered as

soon as possible in the process of PT systems deployment so that the systems deployed are “future proof”

in the sense that they will allow in the future the development of regional information services.

Similarly, in the case of PT systems already in place, the following requirements should be considered as

soon as there is an opportunity to extend the functionality of existing systems.

Basic compliance is mainly a preparatory stage and is not focused on the development of information

services themselves, but includes requirements to make possible that such information services can be

developed at any moment in the future.

BACKGROUND DATA

Systems that maintain background data describing names, location and identifiers of stations and/or bus

stop should be able to provide snapshots of the data using Transmodel-based interfaces.

Systems that maintain information of public transport lines should be able to provide snapshots of the data

using Transmodel-based interfaces.

Systems that maintain timetable information should be able to provide snapshots of the data using

Transmodel-based interfaces and refer to the common identifiers for stops and lines and provide unique

journey identifiers for the planned service journeys.

It should be noted that a basic level of interoperability can be accomplished also if planned timetable data is

not available in advance as long as identifiers for stops and lines are harmonized and the respective AVMS

provides details of current journeys. This means that at the basic compliance level it is acceptable that this

requirement only applies when procuring new systems, while at medium compliance level it also applies to

systems already in place.

Real-time information systems that monitors a public transport vehicle fleet should be able to provide the

different vehicles’ recorded arrival and departure times to the different stops using journey-centric

Transmodel-based interfaces and include references to the relevant journey, stop and line according to the

G03-2015V1 Backoffice systems interoperability Guidelines 11/14

common set of identifiers. If the attached systems can calculate arrival and/or departure prognosis, then this

information should also be provided in the journey-centric Transmodel-based interface.

NETWORK

Any data communication between different Back-offices should be conducted via a secure IP connection

such as VPN connections over Internet.

The same requirement applies for the data communication between any Back-office and any sub system

that is not implemented within the Back-office network.

Figure 6 - Example of data communication structures

3.2 Medium ITxPT compliance

In addition to the Basic compliance requirements the following requirements apply:

SYSTEMS AND SERVICES

3.2.1.1 Background data

There should be systems that maintain planned timetable information and they should be able to provide

snapshots of the data using Transmodel-based interfaces and refer to the common identifiers for stops and

lines and provide unique journey identifiers for the planned service journeys.

There should be an integrator system that assures that all provided background data is consistent with

other data before accepting the information.

G03-2015V1 Backoffice systems interoperability Guidelines 12/14

Consistent and harmonized information describing all relevant stops, stations and lines in the region should

be available on Transmodel-based interfaces.

Attached systems that provide timetable information should import and use the centralized information of

relevant stops, stations and lines to assure consistency with deliveries from other systems.

3.2.1.2 Real-time information

The integrator system should be able to provide requested/subscribed subsets of the harmonized real-time

information to interested parties in journey-centric and stop-centric views on Transmodel-based interfaces.

DPI and AVMS functionality should be separated and all communication between them should pass through

the integrator system using appropriate Transmodel-based interfaces.

3.3 High ITxPT compliance

In addition to the Medium compliance requirements the following requirements apply:

SYSTEMS AND SERVICES

3.3.1.1 Background data

Systems that maintain background data must be able to handle multiple versions of objects. If stations or

bus stop will be renamed, moved or otherwise changed from a certain date in the future the export should

include both the current version and future versions in the same delivery using Transmodel-based

interfaces.

Attached systems that provide timetable information should not administrate identifiers for bus stops or

stations locally but use background data describing names, location and identifiers of stations and/or bus

stops from the central integrator.

3.3.1.2 Real-time information

AVMS should not administrate the timetables locally but use appropriate Transmodel-based interfaces to

get access to the planned timetable from the integrator system.

This does not exclude that, depending of division of responsibility between PTA and PTO, that planning

data is also provided from the PTO, through a dedicated planning system or a combined AVMS and

planning system.

3.3.1.3 Disruption and deviation information

Short term changes in relation to the timetabled plan should be reported explicitly to the integrator using the

appropriate Transmodel-based interfaces. This includes cancelled journeys, partially cancelled journeys,

additional journeys (journey creation), change of journey pattern, change of journey timing as well as

cancelled, changed and added connection protection. This could be the task of an integrated AVMS and

operation control system or be provided from a separate operation control system or other system. There

could also be multiple parallel providers of short term changes.

The integrator should apply and expose the consequences of all short term changes in the harmonized real-

time information it provides through Transmodel-based interfaces.

G03-2015V1 Backoffice systems interoperability Guidelines 13/14

Disruption information should be related to the affected lines, journeys and stops and reported explicitly to

the integrator using the appropriate Transmodel-based interfaces. There could be multiple parallel providers

of disruption information.

The integrator system should apply and expose the disruption information applied to the relevant journeys

and stops in the harmonized real-time information it provides through Transmodel-based interfaces.

DPI systems should use the harmonized real-time information including appropriate deviations and

disruptions,

G03-2015V1 Backoffice systems interoperability Guidelines 14/14

4 APPLYING ITS DIRECTIVE 2010/40/EU

Below is a slightly condensed version of the text in annex II of ITS Directive 2010/40/EU:

The selection and deployment of ITS applications and services shall be based upon an evaluation of needs

involving all relevant stakeholders, and shall comply with the following principles. These measures shall:

(a) Be effective

(b) Be cost-efficient

(c) Be proportionate – provide, where appropriate, for different levels of achievable service quality

and deployment

(d) Support continuity of services – ensure seamless services when ITS services are deployed.

(e) Deliver interoperability – ensure that systems and the underlying business processes have the

capacity to exchange data and to share information and knowledge to enable effective ITS service

delivery;

(f) Support backward compatibility – ensure, where appropriate, the capability for ITS systems to

work with existing systems that share a common purpose, without hindering the development of

new technologies;

(g) Respect existing national infrastructure and network characteristics

(h) Promote equality of access

(i) Support maturity

(j) Deliver quality of timing and positioning

(k) Facilitate inter-modality

(l) Respect coherence – take into account existing Union rules, policies and activities which are

relevant in the field of ITS, in particular in the field of standardisation.

- §§§ -