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