Public Transport

.

17.0 Public transport application areas described

17.0.1 Transport context

The purpose of public transport is to facilitate mobility for people which is beyond what they are able to do with their personal transport facilities. By definition, this will involve a relationship between a travelling person and an external public transport service provider.

Public transport may be delivered either on a social basis (through public services, provided more or less directly by a city, region or country) or on a commercial basis (provided by a – usually profit-making – private-sector company). While these have different financial goals, the mechanisms used to deliver them are identical.

Public transport often involves a wide variety of systems – although contexts vary widely, and not all systems will be relevant to all contexts. This section presents ITS standards under the following functional areas.

Some services which are not “public transport” may also make use of these functions.

NOTE: Systems related specifically and solely to the construction and maintenance of public transport vehicles are not addressed in this document.

17.0.2 Scope of this section

There is no definitive categorisation of what does, or does not, constitute public transport. Typically, it refers to personal transport (i.e. non-freight) transport services in which a service provider owns vehicles and employs drivers, and any person is permitted to use upon purchase of a suitable ticket; that is, the provider is a “public transport operator”. However, there are many exceptions:

It is possible for the vehicles to be driverless, as with an increasing number of trials with automated vehicles. In addition, some forms of transport do not require a driver, for example public cycle hire services.
It is possible for the provider not to be the operator. For example, a city may issue travel tickets to the public, but contract out operations to private sector operators. “Mobility as a service” (MaaS) concepts allow for even more intermediation.
A ticket may not be necessary. The system may be free to use, as for example many airport shuttle buses. It might be paid for through corporate agreements, on a charter basis. Also, the traveller may be charged on an indirect (perhaps bulk-purchase) basis, for example through carnets, season tickets, or personal accounts with capped period costs.
Service might not be available to all people. For example, school transport services are limited to use by children travelling to or from school, while rail-replacement buses are limited to use by those holding a relevant rail ticket.

Conversely, some services that fulfil these criteria are often not considered to be public transport. Car and van rental services are an example. Taxis, too, are often regarded as being a competitor to, rather than a type of, public transport. There are also many “micro-mobility” solutions that are normally excluded, such as travelators and public lifts.

Although some elements will have slightly wider applicability, this section principally addresses standards for the ITS which is used in the context of road-based public transport:

Operational standards for non-road modes (for example, systems for railway signalling systems and air traffic control) are highly regulated and outside the scope of this document.
Rail information standards are addressed in Section 18 (Railway traffic information).
General (primarily road-based) travel information is addressed in Section 22 (Traffic and Traveller Information).

17.0.3 Overview of stakeholders/actors

The actors in public transport vary considerably by context, but will include at least the following:

The public transport authority: the body or bodies responsible for ensuring sufficient provision of public transport services in an area (or of a kind, etc.).
The public transport operator: the body or bodies responsible for providing suitable vehicles and ensuring they make the appropriate journeys.
The public transport service provider: the body or bodies responsible for authorising a traveller to use a specific vehicle journey.
The traveller.

As noted above, the role of public transport service provider will often – but not always – be taken by either the public transport authority or the public transport operator, and will often – but not always – be based on issuing tickets (or a proxy for tickets).

Public transport operates on a transport infrastructure, and is usually subject to local policies of modal choice and environmental protection. There is therefore usually a considerable need for public transport authorities to work with traffic managers, and it is common to see operational systems links between public transport ITS and the ITS used for traffic management and control.

On the other hand, public transport also has a critical relationship with the people who travel on it (or wish to do so). There is therefore an equally important link with systems used to provide traffic and travel information, which may include third party service providers.

Deployment and use of public transport ITS are subject to the usual processes: service design, procurement, service operation, maintenance, etc. Associated with this is a range of stakeholders including external advisers, vehicle manufacturers, national and European legislators, the financial sector (for settling ticket costs), operators of vehicle fleets, and of course the systems industry that designs, builds and maintains the ITS technology used.

17.0.4 Links to other ITS services

As noted above, public transport has interactions with other service domains, particularly road spatial data (see Section 19), traffic management and control (Section 21), and traffic and travel information (see Section 22). Other sections also have connections to public transport, as indicated below.

17.0.4.1 Links with road spatial data

Since transport authorities are generally supportive of public transport, there are policy reasons for them to prioritise the flow of public transport vehicles on the road network. Particularly for the purposes of scheduling, the availability of features such as bus lanes and bus bays is important for public transport operations. Equally important is the absence of geometries that complicate the manoeuvrability of large vehicles: tight turns, low bridges and narrow tunnels, steep hills, etc.

These issues are handled in Section 19.

17.0.4.2 Links with traffic management and control

Complementing the role of road spatial management, traffic managers will seek to ensure that public transport operations are made aware of relevant facilities and challenges. Currently this is largely through fixed information with relevance to all traffic (for example, signage for low bridges or no-entry signs).

Vehicles on diversion from scheduled routes, as well as demand-based services, are more likely to need ad hoc information about the road network. However, this may also be applicable to services on their scheduled routes. For example, this will include the nature, duration and impact of roadworks, as well as current congestion conditions.

Traffic managers have a small number of active tools that can be used to assist public transport:

Selected vehicle priority at traffic signals (reducing the time that a public transport vehicle is likely to wait at a red signal)
Zone access control (enabling passage by public transport vehicles at points on the network where access is barred to general traffic)

These are handled in Section 21.

17.0.4.3 Links with traffic and travel information

A large proportion of travel information pertains to public transport: while users of private vehicles need to know about road conditions, user of public transport services also need to know about the vehicles that are available, how they are currently running, and what the associated costs and restrictions are.

This section will cover tools specifically related to mechanisms that are normally embedded in public transport operational architectures (for example, bus stop signage), but Section 22 covers the mechanisms used for publication of specific information types.

There is a complex link, however, since much of the information generated in operational systems will also be relevant to travel information systems. The onus is therefore on the information service provider (whether a public transport authority, an operator, or a third party) to capture highly-formalised operational information on schedules, live running data, fare tables etc., and convert it into a form that can be presented to (and where appropriate interrogated by) a travelling person – typically by some form of web or mobile interface.

17.0.4.4 .Links with other services

Other service interactions include with:

Parking (Section 16), both for parking points/zones specifically aimed at public transport vehicles (layover points, etc.) and more generally for modal integration with private vehicle traffic (for example, Park & Ride sites).
CCAM & Connected vehicles (Section 9:) it is widely expected that public transport vehicles will continue to be early and innovative users of connected and automated vehicle technologies.

17.1 Public transport architectures

17.1.1 Purpose

The purpose of this functional area is to integrate systems and tools needed to enable effective public transport services.

The tools in this application domain need to:

align with, and support, policy choices and decisions
align with, and support, travel demands
take account of the characteristics of the road network (permanent and temporary)
comply with relevant industry regulation

Because delivering effective public transport is an activity that typically involves a number of different stakeholders, architectural considerations tend to be an important part of getting actors’ systems to work coherently. Issues of openness, non-discrimination, security, etc. all need to be addressed across the market, whether by formalised technical regulation, or by some form of voluntary agreements (with a central coordinator), or by a mixture of the two.

17.1.2 Actors

Different aspects of public transport operations involve a wide range of actors, as described in sections 17.2 et seq. Each separate service area will have requirements for its systems to interconnect to those of other service areas, and this will be the basis for overall architecture design.

The task of designing, delivering and managing an overall architecture is likely to be a focussed led by senior managers in the core actor bodies (public sector authority, provider, and operator), perhaps also with input from regulators. However, each of these bodies controls only part of the architecture, and the number of interfaces between them can be large and complex. There are therefore likely to be many lower-level discussions around architectural design cooperatively between the entities.

To complicate matters further, there is no single model describing which actors take which roles in the overall delivery of public transport services.

17.1.3 System context

Public transport provides a complex system environment. At high level, the system context for traffic management is that shown in Figure 17.0 below. However, this diagram can presents only a minimal set of common functional blocks. In addition to the essential links shown here, there are many other options for data to be cross-linked, linked externally, or fed back to other functions. For further detail on the individual components, and of likely links, please see the relevant functional area description elsewhere in this section.

Also, there are many systems outside the pure ITS environment too, such as human resource systems or complaints handling systems, that will need links to functions shown here. These systems might be subject to particular (regulatory or technical) constraints. Describing these is outside the scope of this document.

Figure 17.0: high level systems architecture for public transport

17.1.4 Related standards

Standardisation of public transport ITS architectures is extensive and mature. In the European context, the central reference model for this is Transmodel (EN12896 series). The current version is documented in eight normative specifications and one guidance document:

EN 12896-1:2016: Public transport - Reference data model - Part 1: Common concepts

EN 12896-2:2016: Public transport - Reference data model - Part 2: Public transport network

EN 12896-3:2016: Public transport - Reference data model - Part 3: Timing information and vehicle scheduling

EN 12896-4:2019: Public transport - Reference data model - Part 4: Operations monitoring and control

EN 12896-5:2019: Public transport - Reference data model - Part 5: Fare management

EN 12896-6:2019: Public transport - Reference data model - Part 6: Passenger information

EN 12896-7:2019: Public transport - Reference data model - Part 7: Driver management

EN 12896-8:2019: Public transport - Reference data model - Part 8: Management information & statistics

CEN TR 12896-9:2019: Public transport - Reference data model - Part 9: Informative documentation

It will be noted that these form a modular structure, although they form a single coherent model. This modularisation is a relatively recent development designed to improve the accessibility of EN12896 series documents.

Supplementing Transmodel is the following publication, which goes some way towards extending the model from its roots in “traditional” public transport (bus, tram, metro, rail etc.) into the newer worlds of shared mobility, micro-mobility and MaaS:

CEN TS 17413:2020: Intelligent transport systems - Urban ITS - Models and definitions for new modes

Transmodel is a relatively abstract tool, but there are many standards which provide more concrete specifications for particular parts of the public transport domain. Of these, the most substantial is the NeTEx family (EN 16614 series), which applies ion particular to route planning (section 17.2), stop management (section 17.4) and fare planning (section 17.6). In addition, the following have a broader function:

CEN TR 16959:2016: Public transport - Network and Timetable Exchange (NeTEx) - Examples, guidelines and explanatory materials

CEN TS 16614-5: Public transport - Network and Timetable Exchange (NeTEx) - Part 5: Alternative modes exchange format

Outside Europe, public transport is even more variable in its implementation, and accordingly there are fewer standards specifically for public transport at ISO level. However, the following may be mentioned:

ISO 17185-1:2014: Intelligent transport systems — Public transport user information — Part 1: Standards framework for public information systems

ISO TR 17185-2:2015: Intelligent transport systems — Public transport user information — Part 2: Public transport data and interface standards catalogue and cross references

Finally, since one of the key aims of public transport is to help individual travellers, issues related to GDPR are highly relevant. In this regard, the following is a useful guide:

CEN TR 16742:2014: Intelligent transport systems - Privacy aspects in ITS standards and systems in Europe

17.1.5 Legislation & Regulations

There is currently no Europe-wide legislation that requires a specific approach to be adopted to public transport system architectures. However, Directive 2010/40/EU, “on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport” (the “ITS Directive”) explicitly mandates the use of some Transmodel-based standards, particularly NeTEx and SIRI, for a wide range of outputs, specifically those related to multi-modal information.

This Directive has been amended by Decision (EU) 2017/2380 of the European Parliament and of the Council of 12 December 2017 amending Directive 2010/40/EU as regards the period for adopting delegated acts

Systems using data that may be considered personal (generally originating in the “detectors” and “connected vehicles” architectural components) will be subject to European regulation on the processing of such data, that is to say to GDPR. This may have implications for, principally, cybersecurity design and practice across the architecture.

PT 17.0 Areas

PT 17.1 Architectures

17.2 Route and timetable planning

17.2.1 Purpose

The purpose of this functional area is to establish a programme of public transport services, indicating when and where they will be made available.

Public transport planning is generally a medium-to-long-term activity, taking into account known and projected levels of demand, operational constraints, and available resources. The aim is to create a basis for the delivery of public transport that can be offered to the public, and is practical for public transport operators (both individually and collectively).

The results may or may not have the force of contract on the operators, and may or may not be subject to regulatory requirements.

As the basis for the public offer, the resulting plans are critically required during the operational management of services, as well as the publication of public transport information.

17.2.2 Actors

There are two general use cases for this function:

Cases where the public transport authority plans routes/timetables, on a city-wide or region-wide basis, and then engages with public transport operators to fulfil the schedule of routes/timetables it has developed. The principal goal here is the fulfilment of demand in line with policy.
Cases where the public transport operator, sometimes acting in the private sector on a commercial basis, determines which routes/timetables it wishes to operate with the vehicles at its disposal. The principal goal here is to maximise benefit (profit, universal accessibility, etc.).

Depending on the organisational structure locally, the two cases may be undertaken in the same organisation or in separate organisations.

In practice, there is likely to be an iterative process between the two use cases:

Demand data are used to generate an “ideal” set of routes and timetables.
An understanding of available vehicles is used to fulfil this ideal set as fully as it can – inevitably this is not completely.
The demand-led process evaluates the consequences and revises its “ideal” set.
Etc.

Feedback from this process can be useful to assist decisions on investment in new vehicles (or indeed the disposal of unnecessary vehicles).

This iterative process, and resultant conclusions on investment, are particularly significant when there is a clear commercial boundary between (public sector) planning authority and (private sector) transport operator.

Plans may be subject to regulatory oversight and approval by an external authority.

17.2.3 System context

Route and timetable planning is often a largely standalone activity, in which authorities or operators use their creativity to generate appropriate route/timetable plans. However, the process becomes much more efficient if there is direct system access to the relevant available assets:

Geographical information relating to the road network, rulesets (speed limits, one-way roads, etc.) and associated infrastructure (stops, bays, etc).
(for operator planning) Available vehicles and their characteristics (capacity, physical size, additional facilities).

It may also be beneficial to have the ability to capture available demand data electronically, to enable algorithmic demand matching in the planning system.

Figure 17.1: systems for route/timetable planning

17.2.4 Related standards

The key European standards for this service area are provided by the NeTEx family, and specifically the following:

CENTS 16614-1:2020: Public transport - Network and Timetable Exchange (NeTEx) - Part 1: Public transport network topology exchange format

CEN TS 16614-2:2020: Public transport - Network and Timetable Exchange (NeTEx) - Part 2: Public transport scheduled timetables exchange format

In the specific case of public transport services that operate on guided routes, the following ISO standard (currently under development) may be relevant.

ISO WD 4398: Intelligent transport systems — Guided transportation service planning data exchange

Route and timetable planning systems have important connections a number of other service areas, on which the following sections provide additional information:

Section 17.3, Stop and station infrastructure management (since each route will require a suitable set of stop points or stop zones)
Section 17.4, Vehicle access to restricted network infrastructure (in case the route passes through a controlled zone)
Section 17.12, Meeting passenger demand (at a strategic level)

Section 19 on road infrastructure (primarily for stops and stations)
Section 22 on travel information (of which public transport information is a core component)

17.2.5 Legislation & Regulations

There is no Europe-wide legislation that directly requires a specific approach to be adopted to route and timetable planning. However, under the ITS Directive, Delegated Regulation (EU) 2017/1926 “Provision of EU-wide multimodal travel information services”:

… Transport authorities, transport operators, infrastructure managers or transport on demand service providers shall provide the static travel and traffic data and historic traffic data listed in point 1 of the Annex, of the different transport modes by using… one of the following standards and technical specifications: NeTEx CEN TS 16614 and subsequent versions, technical documents defined in Regulation (EU) No 454/2011 and subsequent versions, technical documents elaborated by IATA or any machine-readable format fully compatible and interoperable with those standards and technical specifications.

NOTE: DATEX II (for road traffic) and INSPIRE (for geographical information) are also cited in this clause.

“Static data” is defined in the Annex to the Regulation, and includes, inter alia, “identified access notes”, “timetables” and “vehicles”.

As part of the policy inputs to public transport planning, Directive 2008/50/EC of the European Parliament and of the Council, 21 May 2008 “On ambient air quality and cleaner air for Europe” is an important piece of contextual legislation, in that it may oblige authorities to fulfil a significant part of their local transport demand through public transport (and therefore provide the necessary investment).

Geographical information systems are the subject of Directive 2007/2/EC, “Establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)”, and the subsequent Regulations associated with it. This issue is fully addressed in section 19 on road infrastructure.

17.3 Stop and station infrastructure management

17.3.1 Purpose

The purpose of this functional area is to maintain a register of points or zones which public transport services will serve, together with the facilities available at each.

Some services offering transport to the public – notably taxis – are essentially independent of geography, and are able to operate freely on the road network (except where stopping/parking is not permitted, such as on major highways). “Demand responsive” buses often adopt a similar approach.

However, for a lot of public transport, it is of the essence to operate with a limited number of fixed points or slightly larger “stop zones”. This is usually very important in order for the service to achieve the necessary predictability for users, as well as efficiency in operation.

With designated stops, it becomes possible to provide additional facilities, such as passenger shelters, ticket machines and information signage. Hence, public transport networks usually involve an asset base of stops, suitably deployed around the road network, and made available to relevant public transport services that pass them.

This function is essentially an asset management function. The operational use of electronic equipment at the stop/station is undertaken elsewhere.

17.3.2 Actors

This function is almost always led by the public transport authority, especially where it involves physical management of the roadspace,

installation of electricity supplies, etc. However, it will be responsive to requests from public transport operators who wish to develop routes where the existing stops do not provide an adequate basis of operation.

Maintenance at stops will often be triggered by a fault report from a transport operator, or from a member of the public.

17.3.3 System context

Stops and stations can vary greatly in their complexity, and a number and type of systems used – as well as the systems links to external organisations – will reflect this. However, while many of the facilities provided at stops/stations will be ITS (and have their own uses and linkages), the function of stop/station management sensu stricto is – in common with other asset management functions – largely a standalone activity.

For the purposes of public transport operation, the key role of these systems is to publish data on the current catalogue of stops in an area: physical location, whether currently in use or not, and available services at the stop. This is principally an input to route and timetable planning (see section 17.2) but may also be directly used by some other systems, as noted elsewhere.

17.3.4 Related standards

The key European standards for this service area are provided by the NeTEx family, and specifically the following:

CEN TS 16614-1:2020: Public transport - Network and Timetable Exchange (NeTEx) - Part 1: Public transport network topology exchange format

Stop and station management links to the following other sections, which provide additional relevant guidance for specific contexts:

Section 17.2, Route and timetable planning (since routes are typically designated by providing a sequence of stops)

Section 19 on road infrastructure

17.3.5 Legislation & Regulations

NOTE: DATEX II (for road traffic) and INSPIRE (for geographical information) are also cited in this clause.

“Static data” is defined in the Annex to the Regulation, and includes, inter alia, “identified access notes”.

Other regulations may also apply to other aspects of stop/station management; for example, regulations applicable to stop accessibility by disabled people. While they will not directly impact the standards used for management systems, they may impose functional requirements to track and monitor accessibility data (the existence/status of ramps or steps, voice announcements, etc.). It is outside the scope of this document to provide a definitive guide on this issue.

PT 17.1 Architectures

PT 17.2 Route Plaaning

PT 17.3 Stop Infrastructure

Real time Information

Performance Monitoring

Regulations

PT 17.4 Vehicle Access

17.4 Vehicle access to restricted network infrastructure

17.4.1 Purpose

The purpose of this functional area is to enable some or all public transport vehicles to gain access to elements of the road network that are not available for general road users.

Typical examples of restricted infrastructure include bus lanes, bus-only zones, or designated parking areas.

The nature of the restriction varies widely. At one extreme there might be only a few specific public transport vehicles permitted to access a road element. At the other extreme, an element might be accessible not only to all buses but also to cyclists, motorcyclists, taxis, private electric vehicles, and possibly others – but not “all traffic”.

From the traffic manager’s perspective this function is fully covered in section 21: traffic management, zone access control. The description in the present section:

Applies only to the operator’s ITS (and its interface with road management systems).
Is relevant in circumstances where the road element is limited essentially to public transport vehicles only.

17.4.2 Actors

This function involves both the road network manager (and/or traffic manager, if different) and the relevant public transport operator(s). The active role of the operator is what makes this a public transport function.

The operator’s part is to identify the permitted vehicles, in such a way that the road network manager can either

(a) enable access to the restricted road segment or

(b) ensure that no penalty is applied which would otherwise be appropriate.

17.4.3 System context

There are many ways in which an operator can identify his vehicles, and clearly the choice of approach must be collaborative between the operator and the relevant network manager.

The simplest approach pertains when the network manager uses recognition mechanisms such as ANPR to identify vehicles which do not require an active connection. The requirement on the operator is then simply to ensure that the network manager is provided with an up-to-date list of its vehicle registration numbers.

The operator’s role is similarly passive if identification is achieved through other vehicle markers, such as RFID tags, QR codes, driver-carried smartcards or engine-based AVI systems (section 7.11[Architecture/AVI]).

A more active approach is often taken, however, in which the public transport operator actively announces the position and movement of a vehicle to the road network, and requests access. This approach is particularly common where “hard” access control measures, such as physical barriers, are used.

NOTE: This architectural link is technically an example of cooperative ITS (see section 9), but since it antedates the widespread use of C-ITS as a concept, is often treated separately.

Active identification and requests can occur in two ways:

Locally, through a direct interaction between the vehicle and a roadside detector.
Centrally, through a chain in which the vehicle is tracked by the operator’s control centre, which passes position data and perhaps an explicit access request through to the traffic management centre (which can then remotely open a barrier, etc., if necessary).

Local protocols are widely used for physical barriers, where the vehicle is likely to come to a stop anyway. Central protocols are used more often where vehicle flow need not be interrupted, such as for access though bus-only traffic signals.

17.4.4 Related standards

There are no Europe-wide standards specifically focussing on public transport access control systems. However, relevant systems aspects are addressed in the following sections, which may be applicable in some architectures:

In addition, the systems and standards used for Traffic signal priority (Section 17.4) are very similar to those used for access control.

17.4.5 Legislation & Regulations

There is no current EU legislation that constrains the way that access control implements data exchange and algorithms.

17.5 Traffic signal priority

17.5.1 Purpose

The purpose of this functional area is to enable some or all public transport vehicles to secure preferential passage through traffic signals.

Traffic signal priority has, in recent years, become an important part of the toolset used by public authorities to support the policy of supporting public transport, as a part of their responsibilities on managing environmental and accessibility issues. The intention is that granting such preferential passage through signals will improve the speed and reliability of public transport services, in a way that complements (and is often much easier than) infrastructure measures such as designating bus lanes and bus-only zones.

17.5.2 Actors

This function involves the traffic management authority responsible for the traffic signals, and the public transport operator responsible for the vehicles.

The operator’s part is to identify the permitted vehicles, in such a way that the road network manager can try to arrange a green signal for them at each signalised control point. This is not a trivial exercise, and the traffic manager will need to:

Determine the options for signal settings (early green, green extension, green insertion, or of course no action needed).
Determine the impact on the traffic network as a whole, mindful of the fact that interrupting a signal cycle can cause wider problems (of emissions, etc.) that more than negate the benefit of granting priority to the public transport vehicle.
Make any necessary control changes to signal settings.
Possibly, but not necessarily, inform the public transport operator of action taken and reasons.

17.5.3 System context

There are many ways in which an operator can identify his vehicles, and clearly the choice of approach must be collaborative between the operator and the relevant network manager.

As with access control (section 17.4), simple operator-passive solutions are possible and have been used. However, because the aim is to sustain vehicle movement if at all possible, many of these are not practical or efficient, and few passive solutions are now widely used (although ANPR is still a realistic option).

Signal priority is now, therefore, almost always operator-active. Active identification and requests can occur in two ways, each of which has benefits:

Locally, through a direct interaction between the vehicle and a roadside detector.
Centrally, through a chain in which the vehicle is tracked by the operator’s control centre, which passes position data and perhaps an explicit access request through to the traffic management centre (which can then remotely open a barrier, etc., if necessary).

NOTE: This architectural link is technically an example of cooperative ITS (see section 9), but since it antedates the widespread use of C-ITS as a concept, is often treated separately.

17.5.4 Related standards

There are no European standards specifically focussing on public transport access control systems. However, the following international standard is applicable:

ISO 22951:2009: Data dictionary and message sets for pre-emption and prioritization signal systems for emergency and public transport vehicles (PRESTO)

In addition, there are a number of national specifications that apply. An example is the document RTIG-T031, produced by the UK-based public transport forum RTIG (Bibliography).

Related systems aspects are addressed in the following sections, which may be applicable in some architectures:

17.5.5 Legislation & Regulations

There is no current EU legislation that applies to the mechanisms used to provide traffic signal priority.

PT 17.6 Fare Planning

PT 17.5 Signal Priority

17.6 Fare planning

17.6.1 Purpose

The purpose of this functional area is to determine a framework of amounts payable for public transport usage, together with rules for its operation.

Determining fares is a highly complex task, and because it involves financial, personal and contractual transactions, it subject to high levels of scrutiny.

Fares need to be determined with respect to the basis for charging (single and return tickets, day passes and season tickets, carnets, account-based ticketing, etc.), as well as with user type (adult, child, disabled, etc.); also, they will have finite periods of applicability (i.e. start and end dates).

Individual charges for all possible transactions need not always be set specifically in advance, so long as they are in principle determined by transparently-published rules. For instance, with account-based ticketing, it may not be known to either operator or user whether a weekly/monthly cap will be applied, until the end of the relevant period.

17.6.2 Actors

Actors in this function depend on the local business model for public transport provision, but generally involve a combination of public transport authority and public transport operator.

Options include:

Models where fare setting is directly undertaken by the public transport authority, and there is a commercial negotiation between authority and operator on how to address any difference between fare receipts and cost of service provision.
Models where fare-setting is a commercial task but with structural constraints set by regulation (for example, children must be charged no more than half price, or registered disabled people must be free).
Models where fare setting is undertaken by the operator but with regulatory constraints on fare changes (for example, fare increases can only be made at certain times, or are limited to small percentage changes).
Models where fare-setting is purely a commercial task for the public transport operator.

There may in addition be external actors who have a role in publishing the current fares.

17.6.3 System context

Systems involved in fare-planning are highly specialist and contextual, and tend to be more or less linked to other operator financial systems. Interaction between operator and authority will rarely require complex system linkages.

The output of these systems is an approved fares system. The operator will then need to ensure that this is used in all of its ticketing and charging actions. In addition, it will need to make the data available to travel information systems, including any external actors.

Figure 17.2: systems linked to fares planning

17.6.4 Related standards

The following standards are architectural in nature and cover, inter alia, how fare planning relates to operational ticketing and fare collection activities:

EN 12896-5:2019: Public transport - Reference data model - Part 5: Fare management

EN ISO 24014-1:2021: Public transport - Interoperable fare management system - Part 1: Architecture

CEN ISO TR 24014-2:2013: Public transport - Interoperable fare management system - Part 2: Business practices

Operationally, the key European standards for this service area are provided by the NeTEx family, and specifically the following:

CEN TS 16614-3:2020: Public transport - Network and Timetable Exchange (NeTEx) - Part 3: Public transport fares exchange format

Fare planning links to the following other sections:

Section 17.2, Route and timetable planning (fares must be set alongside services offered)
Section 17.12, Passenger journey planning (journey plans will usually need to indicate the cost, and may link directly across to issue of tickets)
Section 17.13, Meeting passenger demand (since this combines with fares per passenger to determine total operator income)
Section 17.14, Passenger bookings and reservations (a charge must be agreed at the point of booking, and may be levied at the same time – even if there is a later change)
Section 17.16, Ticket issue and validation (tickets are priced according to the fare plan)
Section 17.17, Fare collection and account management (money is taken according to the fare plan)

17.6.5 Legislation & Regulations

NOTE: DATEX II (for road traffic) and INSPIRE (for geographical information) are also cited in this clause.

“Static data” is defined in the Annex to the Regulation, and includes, inter alia, “basic common standard fares”.

There are many local regulations that constrain the levels at which fares are set for particular travellers. It is outside the scope of this document to provide a definitive guide on this issue.

17.7 Staff and vehicle assignment

17.7.1 Purpose

The purpose of this functional area is to manage which vehicle and members of staff should deliver each planned public transport journey.

This is an essentially operational function, and is core to the delivery of planned services. Requirements include anticipated maximum passenger load; rarely, there may also be a need for additional facilities (such as unusually high expected demand for wheelchair facilities). Constraints include the vehicles and staff that are available, noting that different vehicles offer different capacity but have different costs of operation, etc.

Assignment may be done through advanced planning, day-to-day operations (particularly in the event of staff or vehicle unavailability), or both.

Vehicle assignment and staff assignment are usually done separately, though this may not always be the case (for example, where each vehicle has a fixed driver or small subset of available drivers that can operate it).

17.7.2 Actors

This function is an internal process within public transport operators, and rarely involves other actors.

In exceptional cases, if the operator cannot fulfil a journey with its own vehicles and staff, it may be feasible to outsource part of all of the delivery: for example, by arrangement with a third party to “borrow” a vehicle and/or driver, or by arranging for taxi services to meet pre-booked demand.

17.7.3 System context

The process of assignment occurs in scheduling and rostering systems, which may (but need not) be connected to the operator’s databases of vehicles and staff.

For operational purposes, the principal output is the operating plan which advises those involved of their assigned duties; again, this is internal to the public transport operator. However, there is often also an important external function to this system, since it enables a planned journey to be monitored:

By authorities, for regulatory purposes (“did the operator comply with his obligation to run the planned service?”).
By authorities, for commercial reasons (“how well did the service run to the contracted performance requirements, in terms of timeliness etc.?”).
By information service providers, in order to input to real time predictions and journey planners.

Figure 17.3: system context for assignment

This system context may be compared to Figure 17.1 in section 17.2 (route and timetable planning). In the latter, the processing is high level and relatively abstract, to identify services which the operator could in principle run with the facilities at his disposal; here, the question is atomic and immediate, and identifies how each service can be practically run.

17.7.4 Related standards

There are few standards directly relevant to the assignment function. For staff assignment the most directly applicable is the following – although it should be noted that this is an abstract model and not a concrete system specification:

EN 12896-7:2019: Public transport - Reference data model - Part 7: Driver management

Vehicle assignment is slightly more formalised, and is embedded explicitly in European standards relating to real time service information – the SIRI standards (EN15531 series). Of these, the most relevant is the following (and particularly the section which describes the SIRI-PT service):

EN 15531-3: Public transport - Service interface for real-time information relating to public transport operations - Part 3: Functional service interfaces

As noted above, assignment links to other functional areas, as described in the following sections:

Section 17.2, Route and timetable planning (this specifies the service journeys for which assignments are required)
Section 17.10, Real time service monitoring (for tracking the real time performance of expected services)
Section 17.13, Meeting passenger demand (especially for demand-responsive services)
Section 17.14, Passenger bookings and reservations (where seats on particular vehicles need to be allocated)
Section 17.19, Service performance monitoring (for regulatory and commercial oversight be authorities)

17.7.5 Legislation & Regulations

There is no Europe-wide legislation that directly requires a specific approach to be adopted to the ITS used in fare planning. However, under the ITS Directive, Delegated Regulation (EU) 2017/1926 “Provision of EU-wide multimodal travel information services” mandates the use of SIRI for the publication of real time data.

PT 17.7 Asset assignment

17.8 Vehicle configuration management

17.8.1 Purpose

The purpose of this functional area is to manage the structure and facilities available on each operational vehicle, taking into account its intended operational role.

Configuration may include facilities for operational use (e.g. communication devices) or for public use (e.g. ticket validators or wheelchair space). In some cases it may also include elements of the vehicle body itself, for example the number of coaches in a designated tram configuration.

As with other aspects of public transport operations, this function has both long term and short term aspects. Long term aspects include the design and procurement of suitable numbers and specifications of vehicles, as well as the fitting of “fixed” ITS tools (including aftermarket systems, mid-life refits, etc.). Short term aspects are those which are arranged on an as-needed basis; for example, ticket machines held as a depot pool and only attached to a vehicle for a particular block of journeys.

17.8.2 Actors

This function is largely an internal process within public transport operators, and often involves no other actors apart from the suppliers of the relevant vehicles and their facilities.

However, the configuration of the vehicle may be constrained by regulatory or contractual obligations. In this case, the constraints may include obligations to:

Use facilities, devices and products provided by an external party
Permit an external party to install, or certify the installation of, specific products
Provide information about vehicle configuration to an external party

Complexities in this function generally arise where multiple systems are involved on the same vehicle, with a need to interwork both with each other and with the operator’s central systems.

17.8.3 System context

The systems environment for managing vehicle configuration involves:

Asset management systems, for the vehicles and the installable facilities.
Specific ITS systems that are themselves installable facilities

Asset management systems, while potentially complex, are not primarily ITS and are largely out of scope of this document. The only general exception to this is the case in which the asset management system also includes direct systems configuration functions, such as device status logging and fault management.

On-vehicle ITS architectures are highly variable. Example of such systems include passenger counting systems, ticket machines/validators, on-board display screens, security cameras, etc. Often these operate on a standalone basis, although there is benefit in providing for a degree of interconnectivity (for example to ensure that different systems have a common value for current time, vehicle location, etc.).

17.8.4 Related standards

The following standard enables information to be exchanged on which facilities are available on board a vehicle, the focus being non-ITS facilities such as wheelchair spaces or toilets:

CEN TS 15531-4:2021: Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring

The principal European standards relating to the configuration management of vehicle-based ITS are those in the EN 13149 series.

NOTE: For historical reasons the general title of the series is “Road vehicle scheduling and control systems”. This is, unfortunately, a slightly misleading title.

Early standards in this series focussed on lower-layer aspects of vehicle systems, and on technologies that were relatively tightly embedded into the vehicle (for example, the communication between engine management, brakes, odometer, door closures, etc.). These have now largely been superseded in favour of the industry-led specifications BusFMS (Bibliography) and the CEN standards are being withdrawn.

More recent parts of the EN 13149 series have, by contrast, focussed on the architecture of systems that are not directly engaged in the vehicle operation; these are generally of greater interest to public transport authorities and passengers, and indeed to operators (vehicle location, on-vehicle signage, ticket machines, announcement systems, etc):

CEN TS 13149-7:2020: Public transport - Road vehicle scheduling and control systems - Part 7: System and network architecture

CEN TS 13149-8:2013: Public transport - Road vehicle scheduling and control systems - Part 8: Physical layer for IP communication

CEN TS 13149-9:2020: Public transport - Road vehicle scheduling and control systems - Part 9: Time service

CEN TS 13149-10:2020: Public transport - Road vehicle scheduling and control systems - Part 10: Location service

CEN TS 13149-11:2020: Public transport - Road vehicle scheduling and control systems - Part 11: Vehicle platform interface service

Vehicle-to-centre communications is not currently the subject of a European standard, although some national specifications have been produced under the auspices of bodies such as RTIG (Bibliography) and VDV (Bibliography). (See also section 8, Communications.)

On-vehicle systems are likely to be involved in many aspects of public transport operations, and often in cooperation with central (fixed) systems. Examples include:

Section 17.2, Route and timetable planning (route/timetable plans may need to be uploaded to the vehicle for use by on-vehicle systems)
Section 17.4, Vehicle access to restricted network infrastructure (whether based on active triggering systems or vehicle location systems)
Section 17.5, Traffic signal priority (whether based on active request systems or vehicle location systems)
Section 17.10, Real time service monitoring (principally related to vehicle location and its match against planned timetables)
Section 17.11, Real time routing control (this requires messaging to/from the driver – or to/from the vehicle, in case of a driverless service)
Section 17.14, Passenger bookings and reservations (in order to designate specific seats)
Section 17.15, Real time information provision (for on-vehicle displays)
Section 17.16, Ticket issue and validation (for on-vehicle ticket machines and validators)
Section 17.17, Fare collection and account management (generally associated with ticket issue, but potentially also undertaken via passenger presence registration)
Section 17.18, Incident management (for typically connected with routing control but sometimes requiring specific communications to passengers)

See also section 9 on cooperative ITS and CCAM.

17.8.5 Legislation & Regulations

There is no Europe-wide legislation that requires a specific approach to be adopted to the management of vehicle configurations.

In rare cases, there may be regulatory requirements for on-vehicle systems. However, these are more likely to be specified either by the operator itself, or sometimes by the relevant public transport authority (especially in cases where the operator is acting under an explicit contract to the authority).

17.9 Hire vehicle management

17.9.1 Purpose

The purpose of this functional area is to manage the deployment of unmanned vehicles made available for public use.

These services vary greatly in which vehicles they use, who may access them, where vehicles may be obtained and relinquished, etc. Typical examples include:

Public shared bicycles which can be picked up from one of a number of racks at various points around a city, and deposited at any other rack.
Car share “clubs”, open only to members (but the membership criteria vary), which may make access available to a small number of specific vehicles at a single point.
Mobility scooters, specifically for use by registered disabled people and limited to a specific context (perhaps a shopping zone or a small residential area).
Autonomous “pods”, which may run on walkways, roads or rails, and are designated for specific transport circuits or stop points (effectively, as a very small metro system).

Operating this model of public transport entails most or all of the typical public transport activities (planning routes, allowing passengers to board, charging passengers for use, providing information to support journeys, etc.). In addition, though, there is a specific challenge for the operator to know where its vehicles are, who is using them, etc., and (if appropriate) move them from one point to another to sustain the service.

NOTE: The term “passengers” is used since this section is related to public transport. This does risk slight confusion, since the “passengers” may well in effect be “drivers” of the vehicles in question (as for instance with hire cycles), but is retained in context. It is potentially more meaningful, for instance, when viewing the user in the context of an intermodal or multimodal journey, which may be subject to unified ticketing.

17.9.2 Actors

This function is largely an internal process within public transport operators, and often involves no other actors (apart from the passengers who use the service).

There may be regulatory obligations on the operator which require periodic management reporting etc.

17.9.3 System context

The systems environment for this function involves principally asset management systems, both for the fleet vehicles themselves and also for the access point facilities.

Figure 17.4: systems context for hire vehicle management

17.9.4 Related standards

Public vehicle hire is a relatively recent concept in public transport, and the mechanisms by which it is achieved are still evolving. There are, therefore, few standards that are directly applicable to this functional area. Of these, the following are the most directly relevant:

CEN TS 17413:2020: Intelligent transport systems - Urban ITS - Models and definitions for new modes

CEN/TS 16614-5: Public transport - Network and Timetable Exchange (NeTEx) - Part 5: Alternative modes exchange format

Depending on specific contextual aspects, several other aspects of public transport management (and the associated standards) may connect with hire vehicle management systems:

Section 17.2, Route and timetable planning (even when there is no specific route or timetable, this kind of planning is relevant to ensure that the location and capacity of access points meets the anticipated passenger demand)
Section 17.3, Stop and station infrastructure management (there are likely to be access mechanisms such as docking stations and lock systems that need management in concert with the vehicles themselves, e.g. to register that vehicle X is currently in docking station Y)
Section 17.7, Staff and vehicle assignment (for example, where a specific vehicle is designated for issue to a requesting passenger)
Section 17.10, Real time service monitoring (it is particularly important for the operator to be able to track movements of vehicles under the control of members of the public)
Section 17.13, Meeting passenger demand (relocating vehicles will be undertaken on the bases of moving them from where they are left to where the next cluster of passenger demand will be)
Section 17.14, Passenger bookings and reservations
Section 17.15, Real time information provision (in order to advise passengers of, for example, where the nearest available hire vehicle is)

Section 9 on cooperative ITS and CCAM is clearly also applicable when the hire vehicles are autonomous or highly automated.

17.9.5 Legislation & Regulations

Under the ITS Directive, Delegated Regulation (EU) 2017/1926 “Provision of EU-wide multimodal travel information services” has provisions that relate to hire vehicles as well as scheduled public transport services. However, these relate to aspects addressed in other sections – for example, location of access points (covered in section 17.2), information on booking systems (section 17.14), and current availability (section 17.15) – and there are no provisions specifically on how vehicles are managed.

Regulatory requirements do, of course, exist widely for the operation of hire vehicle services, although these vary greatly from location to location and from service type to service type: there is little commonality between public cycle hire in Paris, car-share schemes in Prague, mobility scooters in Riga and automated taxis in Barcelona.

PT 17.8 Configuration Mgt

PT 17.9 Hire Vehicles

PT 17.10 Service Monitoring

17.10 Real time service monitoring

17.10.1 Purpose

The purpose of this functional area is to monitor the operation of public transport services against plans.

The principal goal within this is to determine whether the vehicles assigned to operate scheduled services are fulfilling the specification of their routes and timetables, and if not to trigger appropriate corrective action.

Similar functions in non-scheduled services also apply; for example, for an on-demand service, a plan will be created in order to respond to demands, which will then be used as the basis for informing passengers of arrival times; on despatch, vehicles will then be monitored against this plan.

In parallel with operational monitoring, there may be external monitoring to assess compliance with regulation, contracts, etc. This could in principle be independent of operational monitoring, but clearly it is advantageous if the two functions use the same data (as there will be less scope for disputes, etc.).

Although this is a challenging technical environment because it involves real time communications among widely dispersed and (usually) mobile units, the core functionality is relatively simple. Complexity arises principally when problems arise and corrective actions need to be taken by the operator. Corrective actions may include some or all of the following:

Changing the route plan for specific vehicles (for example taking a different set of roads, omitting or calling at additional stops – see section 17.11)
Cancelling specific service journeys
Despatching additional or replacement vehicles
Advising passengers that services how services are operating, and if services are disrupted, helping passengers to replan journeys

Since these management actions are undertaken in response to problems occurring in real time, it can be difficult for operators to ensure that the control decisions are (a) undertaken promptly and effectively by staff, and (b) reflected correctly in systems.

17.10.2 Actors

Operational monitoring is undertaken by (or on behalf of) the public transport operator. Regulatory and contractual monitoring is generally undertaken by (or on behalf of) the public transport authority.

Actor roles can become confused if a public transport authority acts both as a regulator/contracting body, and as an operator. Where roles are not confused, conflicts of interest can still arise, for example when the operator is found not to be meeting timetable targets by the authority, but the operator blames the authority’s management of traffic. This problem is inherent in the allocation of roles and cannot be resolved by system design.

Other role boundary challenges may occur, for example:

Where the public transport authority monitors services on behalf of the operator
Where the operator is required to self-monitor against regulatory or contractual obligations
Where a third party service monitors for both purposes, and provides different (but consistent) reports to operator and to authority

17.10.3 System context

The systems environment for real time service monitoring involves systems that:

Identify and track the movement of specific vehicles
Collate vehicle movements against schedules/plans
Provide reports and, if appropriate, alerts that services are failing to fulfil schedules/ plans adequately

In some cases, the control actions that are undertaken in the event of a problem can be codified and partially automated. Examples include the actions to be taken in the event of roadworks, heavy congestion, and excess passenger demand. This may be either by means of pre-planned “scenarios” or, more subtly, by data-driven triggers. However, it is almost impossible to automate control actions fully; therefore, it is inevitable that circumstances will regularly arise in which “manual” control actions are required.

Figure 17.5: systems for real time service monitoring

17.10.4 Related standards

The key European standards for this service area are provided by the SIRI family, and specifically the following:

EN 15531-1: Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework

EN 15531-2: Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications

EN 15531-3: Public transport - Service interface for real-time information relating to public transport operations - Part 3: Functional service interfaces

CEN TS 15531-4: Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring

In some circumstances, the following ISO standard may be relevant for the initial creation of actual vehicle movement data.

ISO TS 21176: Cooperative intelligent transport systems (C-ITS) — Position, velocity and time functionality in the ITS station

Real time service monitoring systems have important connections a number of other service areas, on which the following sections provide additional information:

Section 17.2, Route and timetable planning (for the schedules against which real time service operation is monitored)
Section 17.5, Traffic signal priority (services running late may preferentially request priority)
Section 17.7, Staff and vehicle assignment (in case control actions require the provision of additional or replacement vehicles)
Section 17.11, Real time routing control (this helps to fulfil any necessary control actions)
Section 17.12, Passenger journey planning (where service disruptions require passengers to be advised on re-planning journeys)
Section 17.15, Real time information provision (to advise passengers and other stakeholders of current operational performance)
Section 17.18, Incident management (incidents are a common cause of disruption)
Section 17.19, Service performance monitoring (this will typically include a summary of real time service monitoring over a period of time)

Section 9 on cooperative ITS and CCAM is also applicable when the public transport vehicles are autonomous or highly automated, both for the provision of vehicle movement information, and potentially also for vehicle re-routing (see section 17.11).

17.10.5 Legislation & Regulations

There is no Europe-wide legislation that directly requires a specific approach to be adopted to real time service monitoring. However, under the ITS Directive, Delegated Regulation (EU) 2017/1926 “Provision of EU-wide multimodal travel information services” mandates the use of SIRI for the publication of real time service data.

17.11 Real time routing control

17.11.1 Purpose

The purpose of this functional area is to advise drivers and vehicles of public transport vehicles to change their current route plans.

A change of route will normally arise as a result of either service disruption or unexpected levels of passenger demand. (In the case of demand-responsive services, new – and by definition unexpected – passenger demand may occur at any time.) Service disruption, in turn, may occur as a result of problems within the operator’s responsibility (for example broken-down vehicle or staff illness) or outside the operator’s responsibility (for example ice, flooding or road accidents).

Advice to drivers may be provided by a senior operations manager or by an automated service optimisation system, though the latter is not widely used at present. Control actions may include diversions, turning early, omitting some stops, returning to depot, or simply stopping as soon as it is safe to do so.

Control actions may be triggered by a driver request (e.g. “I am stuck in traffic, what do you want me to do?”) or by real time service monitoring.

Where public transport vehicles are partially or fully automated, control actions may be direct instructions to the vehicle, i.e. the download of a new planned route (and associated data, for example for on-board passenger information).

17.11.2 Actors

This function is essentially a public transport operator function.

Exceptionally, there may be direct involvement of external authorities; for example it is conceivable to envisage a system where highly automated vehicles might be stopped directly by police services if there were an immediate public danger.

17.11.3 System context

The high-level system architecture for real time routing control is very simple: an operator central system communicates with an on-vehicle driver system. Generally the nature of the communication is straightforward, and may include messages such as:

Change the route plan (for example take a different set of roads, omit or call at additional stops)
Terminate the service journey (for example unload all passengers at the next stop, and return the vehicle to depot)
Continue as planned but await further instructions

The message may be exchanged either on a driver display or by voice communication (where safe to do so with a working driver).

However, the means by which the message is decided is highly complex and almost always the result of human judgment and, often, detailed local knowledge. Moreover, these management actions are undertaken in response to problems occurring in real time. For these reasons, it can be difficult for operators to ensure that the control decisions are:

(a) predictable or consistent,

(b) undertaken promptly and effectively by staff, and

17.11.4 Related standards

As real time routing control principally has an operational management, rather than a technological, focus, there are few standards that address it directly. However the following component of the Transmodel series does present this in the context of an overall public transport systems architecture (see also section 17.1):

EN 12896-4:2019 Public transport - Reference data model - Part 4: Operations monitoring and control

The principal other functional areas connected to real time routing control are as follows:

Section 17.7, Staff and vehicle assignment (for cases when staff and vehicles need to be redeployed, e.g. to supply replacement or additional service journeys)
Section 17.10, Real time service monitoring (this provides a common trigger for control actions)
Section 17.15, Real time information provision (since passengers need to be informed of service changes)
Section 17.16, Ticket issue and validation (this may be necessary if, for example, some tickets that were valid on specific services now need to be admitted on other services)
Section 17.18, Incident management (an incident may provide an advance trigger for control actions, for example if the incident will shortly affect certain services that are currently running smoothly)
Section 17.19, Service performance monitoring (control actions may need to be reported to contextualise service performance reports)

Section 9 on cooperative ITS and CCAM is also applicable when the public transport vehicles are autonomous or highly automated, since this a potential channel for direct vehicle re-routing.

17.11.5 Legislation & Regulations

There is no identified European legislation that determines what systems are used for real-time re-routing.

More widely, there are few if any regulatory obligations on when and how a public transport operator should undertake re-routing, other than through implicit requirements (to operate in the interests of public safety, etc.).

17.12 Passenger journey planning

17.12.1 Purpose

The purpose of this functional area is to allow current and prospective travellers to determine their optimum journey.

A successfully-planned journey should include all of the factors that are relevant to the passenger. From the public transport side this is likely to include routes, modes, times and prices as a minimum. Other relevant factors will be outside the public transport space (for example hotel availability, weather, and local events).

A number of transport-specific factors will be relevant only to a subset of passengers, for example disability support (e.g. step-free access) and environmental impact estimates (e.g. ascribed CO2 emissions).

A planned journey may or may not result in:

The issue of one or more tickets (or other contractually binding step). The traveller may decide not to travel, or to travel by means other than public transport.
An actual journey. If a ticket is issued, there is usually a cancellation opportunity. An intended journey may also be unfulfilled through force majeure, affecting the traveller or the transport operator or both.
A journey that is identical to the planned journey. The traveller’s requirements may change mid-journey, or the planned public transport journeys may be disrupted.

Where a planned journey has been begun, therefore, it may be necessary to re-plan around new circumstances. A new element here is to determine what journeys can now be completed within the authority of, or with minor amendments to, an existing ticket.

Journey planning is an inherently contextual activity and inevitably involves considerable cognitive input from the traveller (or the person planning a journey on their behalf). As a result, there is a lot of scope for variation and creativity in journey planning systems.

17.12.2 Actors

This function involves as a minimum the person planning the journey and one or more public transport operators proposing services that can (help to) fulfil the journey. Public transport operators will therefore usually have a journey planner linked to their own services, and directly connected to a ticketing system (in case the traveller chooses to accept a proposal).

However, journey planning frequently requires the collation of services provided by multiple modes, and/or multiple operators for a specific mode. Such a service can be provided in a number of ways:

By a “main” transport operator, which gathers information from other relevant operators to propose a fuller set of journey options than it is able to provide alone.
By a public sector agency, acting impartially for public transport services in its area of geographical interest. This agency may or may not be connected to the local transport authority.
By a charity, perhaps acting on behalf of people with particular requirements (for example, visually impaired travellers).
By an independent commercial service. Such a service may be funded by advertisement, by subscription from public transport providers, or (rarely) by subscription from public transport users.
By a fully-fledged MaaS provider, which operates no public transport itself, but is able to contract (i.e. “ticket”) a planned journey with the traveller if appropriate. Complexities arise if the planned journey includes operators outside the MaaS provider’s own scope.

17.12.3 System context

A journey planning system is logically separate from operational and information systems in most cases. It requires a user interface, where the traveller can log requirements, view proposals, and amend or accept them. It also requires interfaces with the systems that hold details of public transport services on offer, namely:

Timetable systems for planning of future journeys
Real time information systems for (re-)planning of current journeys

It may also capture information from other systems (geographic information systems, incident management systems, etc.)

Typically the user interface is provided through the traveller’s own device (e.g. through a browser front end or an app). Occasionally it may also be provided through a public access terminal or kiosk.

The figure below indicates the systems involved in the operation of journey planning.

Figure 17.6: systems context for passenger journey planning

7.12.4 Related standards

There are no technical standards that specifically address the algorithmic functionality of journey planners, i.e. the ways in which they select and compile a passenger journey plan from “available” public transport journeys, owing to the high degree of complexity and contextuality.

The following standard, however, specifies the ways in which multiple journey planners can interconnect. This is intended, in particular, to enable the integration of offers from multiple operators, but it is also usable between “independent” journey planners (for instance to enable greater geographical or modal coverage) and between “branches” of a single operator.

CEN TS 17118:2017: Intelligent transport systems - Public transport - Open API for distributed journey planning

A broader review of journey planning, and the use of standards, is provided by the following:

ISO TR 17185-3:2015: Intelligent transport systems — Public transport user information — Part 3: Use cases for journey planning systems and their interoperation

Although it is not directly relevant, the following addresses how information, including journey information, should be made available to passengers with visual impairments.

CEN TR 16427:2013: Intelligent transport systems - Public transport - Traveller Information for Visually Impaired People (TI-VIP)

Journey planning systems need to link to some or all of the systems which are covered in the following sections:

Section 17.2, Route and timetable planning (routes and timetables are the primary input to journey planning)
Section 17.6, Fare planning (where a viable route is found, travellers will usually want to know the likely cost)
Section 17.8, Vehicle configuration management (for cases where the traveller requires vehicles with specific facilities)
Section 17.9, Hire vehicle management (for journey planners that include hire vehicle modes)
Section 17.10, Real time service monitoring (where service operations depart from timetabled plans, this may be a more reliable basis for planning immediate or en train journeys)
Section 17.13, Meeting passenger demand (journey plans can be a source of demand information; also, a journey planner can take into account the fact that some services are likely to be very busy in order to balance passenger loads)
Section 17.14, Passenger bookings and reservations (when a traveller wishes to accept a proposed journey, it is convenient to link directly to a booking system – this will, in turn, link to ticketing and fare collection if appropriate)
Section 17.18, Incident management (incident information can be used to trigger re-planning)

See also section 22 on travel information.

17.12.5 Legislation & Regulations

There is no Europe-wide legislation that directly requires a specific approach to be adopted to passenger journey planning. However, under the ITS Directive, Delegated Regulation (EU) 2017/1926 “Provision of EU-wide multimodal travel information services” recommends the use of CEN TS 17118 for distributed journey planning by local, regional and national travel information service providers.

NOTE: The Delegated Regulation was published prior to the final publication of CEN/TS 17118, which is referred to in the preamble of the Regulation text as “the European Technical Specification entitled ‘Intelligent Transport Systems — Public Transport — Open API for distributed journey planning 00278420’ currently under finalisation”.

The issue of “discriminatory” selection in journey planners is a contentious points of discussion, and there is no uniform regulation that controls it. It is generally acceptable for journey planners to emphasise some modes rather than others (for example, bus rather than private car). However, there may be a breach if directly competing providers (for example, two different bus operators able to serve the same journey) are not treated impartially, unless there is a good reason (for example, one of the operators does not provide sufficient accessible data). This applies especially if there the potential for ticket issue to be triggered.

This is principally a matter for commercial law rather than technical regulation, and specific legal expertise should be sought in this regard. Nevertheless, it has clear technical implications for the design of journey planners.

PT 17.11Routing control

PT 17.12Journey planning

PT 17.13Demand Management

17.13 Meeting passenger demand

17.13.1 Purpose

The purpose of this functional area is to allow public transport services to be adjusted against anticipated passenger demand.

This may take place strategically, in response to changes in the road network or changes in demographics; or tactically, in response to specific and substantial changes in passenger numbers for a short period of time, whether expected (e.g. in anticipation of a sporting event) or unexpected. It may also be built into the public transport operation, i.e. as a demand responsive service.

17.13.2 Actors

This function principally involves public transport operators and public transport authorities.

At a strategic level, public transport authorities attempt to ensure that the provision of public transport in their area of authority is sufficient in terms of routes, stops, frequency and capacity to meet demand, as well as of a sufficiently high quality in other respects (for example, environmental footprint of vehicles or punctuality of services). They do not normally have a tactical role, which is essentially the function of operators.

Strategically, public transport operators need to ensure that they have the vehicles, garages, and staff to operate the services that they have decided or agreed to provide, as well as the necessary systems to monitor and sustain these services.

Tactically and operationally, operators need to ensure that individual vehicles (with drivers and other staff as appropriate) are despatched onto routes in order to fulfil the declared services. However, they may also have a role in monitoring demand in real time, and responding accordingly; this may lead to:

More, more frequent, or larger vehicles being used, and/or more routes being served, if the demand is higher than expected (resulting in better passenger service and usually greater income)
Fewer, less frequent, or smaller vehicles being used, and/or fewer routes being served, if the demand is lower than expected (resulting in lower costs and environmental impact, with minimal loss of service quality)

The extent to which operators can respond tactically to passenger demand depends on three principal factors:

The regulatory environment, which may constrain the service frequency, vehicle type, etc. that the operator is permitted to deliver
The assets available to the operator
The extent and quality of real time data on passenger demand

Passengers also have a potential role in this, through registering their requirement for a journey in a way that is visible to operators. This may be undertaken in advance, through a booking process resulting in a specific journey “contract” (see section 17.14), but may also be declared as a looser aim or as a typical behaviour (for example, a regular journey).

17.13.3 System context

Strategic and tactical demand management activities are largely independent functions in system terms. Occasionally there is feedback from the processes that manage tactical processes into strategic systems, for example around the logistics of managing demand surges.

Strategic demand response uses a range of mechanisms, such as demographic models, historical data and survey information, to determine a demand model. This is then collated against local policy in the process of service planning (see section 17.2).

Tactical demand response is usually considerably more dependent on technological tools. However, the range of inputs to the expected/modelled demand is similarly varied, and includes options such as:

Passenger detection systems, on-vehicle, at stops and stations, and using technologies such as cameras with image analytics and “sniffers” that detect Bluetooth or WiFi signals from personal devices
Booking and ticketing systems – although these are generally only reliable when the operator requires booking for all or most passengers
Interactive applications, particularly in demand responsive transport

Figure 17.7: systems context for meeting passenger demand

Some demand variation involves elements of both planning and tactical control. For example, a major sporting event is known in advance and allows planning (by authority and operator). However the number of attendees, and their chosen travel choices (particularly timing), may be less well known and subject to last-minute adjustment.

For such cases, there is potential for significant mismatch to arise between services and demand, which can lead to loss of reputation, large numbers of complaints, and even public disorder. It is therefore usually beneficial to try to determine specific journey requirements as much as possible in advance, for example through time-specific tickets.

Strategic demand management can also be deployed in exceptional circumstances (as was used in the London 2012 Olympics), through suppression of background demand, selective routing in booking systems and even journey planners, etc.

17.13.4 Related standards

This is a complex area, and there are few standards that are directly relevant to systems used for demand modelling and demand management.

Meeting demand is of course central to the purpose of public transport, and most other sections within section 17 have some link with passenger demand response. The following are, however, have a particularly close connection:

Section 17.2, Route and timetable planning (especially where new routes need to be designated temporarily, and for demand-responsive services)
Section 17.10, Real time service monitoring (essential to understanding how well current demands are being met, and therefore whether further steps need to be taken)
Section 17.11, Real time routing control (this provides tools for managing vehicles that are already operating passenger journeys)
Section 17.12, Passenger journey planning (as an indication of potential demand)
Section 17.14, Passenger bookings and reservations (as a direct indication of minimum demand, but also enabling some demand management such as “service full” messages)
Section 17.15, Real time information provision (particularly important to calm passengers in stressful contexts)
Section 17.18, Incident management (demand frequently changes quite suddenly in the event of incidents)

See also section 22 on travel information.

17.13.5 Legislation & Regulations

There is no identified European legislation that determines what systems are used for passenger demand management.

More widely, there are few if any regulatory obligations on when and how a public transport operator should operate to meet (unexpected) changes in demand. More often, regulation aims to establish a stable, predictable pattern or operations, and responding to demand changes has to be handled as an “exceptional” circumstance.

17.14 Passenger bookings and reservations

17.14.1 Purpose

The purpose of this functional area is to enable prospective passengers to secure a future journey on a specific timed public transport service.

Bookings and reservations are inevitably the outcome of the (informative) journey planning process. If the passenger is happy with the plan, a booking or reservation can then be made to form the basis of a contract between the passenger and the transport service provider (either a public transport operator or a third party such as a MaaS service provider). As such, they codify some of the key aspects of a journey – especially origin and destination, carrier service(s) and timings.

The details of the function will depend on the operational practices of the provider. For example, in some cases a specific seat is identified, while in others it is not. Furthermore, the conditions for cancellation or amendment of the booking vary widely.

17.14.2 Actors

This simplest approach to this function involves just the (prospective) passenger and the operator. The operator identifies a journey offer and presents it to the passenger, who then accepts or refuses it within a specific time (i.e. the validity period of the offer). The contractual nature of the transaction is generally embodied in a ticket.

Third party roles between passenger and operator may be of a number of forms. Examples include third parties who:

Help the passenger to clarify his/her requirements, and then relay acceptance (for example a friend or helper, or a charity)
Provide a journey planning platform which enables and coordinates links to operator booking systems (may independent journey planners will do this)
Hold systems that enable passenger requirements to be circulated to potential operators, and possibly receive a ticket which is passed to the passenger (this is the traditional role of the travel agent)
Act as delegated booking systems for an operator or group of operators, but take no passenger-specific contracting role
Contract directly with the passenger for services, and engage mirrored contracts with operators (as in some models of MaaS provision)

Enabling services may be provided by additional third parties, such as the Global Distribution Systems (Amadeus, Sabre, etc.). However, these are essentially communications channels and take no active part in the booking process.

17.14.3 System context

The function of bookings and reservations is a gateway function between a journey planner and a bookings database. Depending on the business model, the bookings database may lie with the operator or with a third party intermediary.

Because it is contractual in nature, a bookings system will have important requirements including security, archiving, and links to other business systems such as ticketing and complaints management.

The interactions between booking, ticket issue and fare collection are complex. Where an advance booking is made, the booking process may be multi-stage (for example, with a deposit paid on booking, the remainder paid by a later deadline, and a further deadline for cancellation and refund). In this situation, the booking system is likely to lead the control of the process.

17.14.4 Related standards

Booking systems are complex internally and there are currently few technical standards that affect them directly. Equally, the contractual nature of the outcome means that user interfaces are driven as much by commercial pressures as by technical considerations.

Where there is a substantive intermediary, the following standard – primarily concerned with distributed journey planning – helps to support the ways in which bookings are communicated between passenger and operator:

CEN TS 17118:2017: Intelligent transport systems - Public transport - Open API for distributed journey planning

The following standard is primarily aimed at defining fares structures, but in so doing also has relevance to bookings and reservations:

CEN TS 16614-3:2020: Public transport - Network and Timetable Exchange (NeTEx) - Part 3: Public transport fares exchange format

Booking and reservations systems need to link to some or all of the systems which are covered in the following sections:

Section 17.12, Passenger journey planning (much the most common point from which a booking originates)
Section 17.16, Ticket issue and validation (the issue of an advance ticket is often an integral part of establishing a booking)
Section 17.17, Fare collection and account management (payment, in part or in full, is also often part of the booking process)

See also section 22 on travel information.

17.14.5 Legislation & Regulations

There is no identified European legislation that determines what systems are used for bookings and reservations.

Since bookings and reservations involve an element of contracting, prevailing commercial law is relevant to the systems used for them, and specific legal expertise should be sought in this regard.

17.15 Real time information provision

17.15.1 Purpose

The purpose of this functional area is to provide information about the current operation of public transport services.

There are three general use cases for this.

The first use case is the provision of information about the status of the specific public transport services delivered (or scheduled to be delivered) by a public transport operator. Information is generally factual and specific. Typical examples include “service 16 is 5 minutes behind schedule” and “service 16 is cancelled”.
The second use case is the provision of higher-level kinds of real time information about transport services (environmental, multi-operator, context-dependent, etc.). Information may be less specific and may include some judgment. Typical examples include “bus services are subject to disruption until 17:00 owing to poor weather”.
The third use case is the provision of passenger-specific information, which may be linked to a specific journey that the passenger is on or has planned (see section 17.12). This kind of information may include travel advice; for example “your current bus is running 5 minutes late and will arrive at 13:15, and your next connecting service will depart at 13:26”.

The nature and type of information provided will vary depending on who is providing the information, the channel of dissemination, and the extent to which the user can select parameters (geographic, date and time, etc).

Real time information is often but not always accompanied by schedule information (e.g. the currently expected time of arrival of a public transport vehicle, alongside its scheduled time of arrival).

17.15.2 Actors

Public transport authorities and their system suppliers; Public transport operators and their system suppliers; Information service providers.

Numerous actors are involved in the provision of real time information provision, including:

Public transport operators – specifically or primarily for their own services
Public transport authorities, for the geographical area and modes which are their responsibility
Independent information service providers, often with a specific commercial focus of interest
Charities, especially disability charities, who are able to provide contextualised information (for example that a particular service vehicle is or is not wheelchair accessible)
Travel destinations (shopping centres, business parks, event organisers, etc.) regarding the public transport services that serve them

17.15.3 System context

Real time systems involve the following general stages:

Identify which services are supposed to be operating, and to what timetable.
For in-service vehicles, use monitoring data to determine how well these are being delivered.
Gather external information to identify externalities that will affect the ability of the public transport system to operate as scheduled – especially environmental issues such as poor weather, network issues such as congestion or accidents, and perhaps demand-side issues such as major events.
Using available data, predict how public transport services will actually behave, in the short term future (typically the next hour or two, but for major problems, sometimes longer)
Present these predictions via publicly accessible systems (such as signs and public address systems), and also on request (from websites, apps, etc.)

Different actors will choose to interpret each of these steps according to their specific organisation’s goals. Generally, public transport operator data will be captured first (see section 17.12) and will form the input to all of these systems.

The figure below indicates the systems involved in the operation of real time information provision.

Figure 17.8: systems context for real time information provision

.

17.15.4 Related standards

The principal European standards relevant to the structuring and publication of real time service information are those in SIRI series (EN 15531 series). See particularly the following:

EN 15531-3:2015: Public transport - Service interface for real-time information relating to public transport operations - Part 3: Functional service interfaces

CEN TS 15531-4:2021: Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring

CEN TS 15531-5: Public transport ‐ Service interface for real‐time information relating to public transport operations ‐ Part 5: Functional service interfaces situation exchange: Situation Exchange

For presentation to passengers and other members of the public, there are some standards specifically focussed on visually impaired people:

CEN TS 15504:2007: Public transport - Road vehicles - Visible variable passenger information devices inside the vehicle

CEN TR 16427:2013: Intelligent transport systems - Public transport - Traveller Information for Visually Impaired People (TI-VIP)

The following standards (part of the TPEG series) describe the presentation of public transport information over broadcast channels – however as “TPEG1” these are in the process of being superseded by “TPEG2” standards:

CEN ISO TS 18234-5:2006: Traffic and Travel Information (TTI) - TTI via Transport Protocol Expert Group (TPEG) data-streams - Part 5: Public Transport Information (PTI) application

CEN ISO TS 24530-4:2006: Traffic and Travel Information (TTI) - TTI via Transport Protocol Experts Group (TPEG) Extensible Markup Language (XML) - Part 4: tpeg-ptiML

NOTE: the TPEG2 replacement is expected to be published as ISO/TS 21219-13, with the title “Intelligent transport systems — Traffic and travel information via transport protocol experts group, generation 2 (TPEG2) — Part 13: Public transport information service (TPEG PTS)”

The standards relating to the protocol suite RDS-TMC (described fully in section 22, Traffic and travel information) include the following; this relates primarily to traffic information but coves some elements of public transport as well:

EN ISO 14819-2:2013: Intelligent transport systems - Traffic and travel information messages via traffic message coding - Part 2: Event and information codes for Radio Data System - Traffic Message Channel (RDS-TMC) using ALERT-C

A more general resource for passenger information is provided by the following standard (part of the Transmodel series):

EN 12896-6:2019 : Public transport - Reference data model - Part 6: Passenger information

Real time information systems need to take data from some or all of the systems which are covered in the following sections:

Section 17.2, Route and timetable planning (this sets the baseline for fixed-route services relative to which real time information is to be provided)
Section 17.9, Hire vehicle management (where real time information is largely limited to the availability of vehicles at access points)
Section 17.10, Real time service monitoring (this is the means by which an operator determines how well an in-service vehicle is fulfilling its journey schedule)
Section 17.11, Real time routing control (information on diversions, cancellations etc. is critical to passengers)
Section 17.14, Passenger bookings and reservations (passengers can be specifically notified of the real-time status of their booked journey)
Section 17.16, Ticket issue and validation (particularly relevant is the situation where, because of service disruption, a ticket’s validity is extended to other journeys or other modes)
Section 17.17, Fare collection and account management (in cases where fares are variable, this may be necessary component of real time information)
Section 17.18, Incident management (where an incident affects services, passengers need to be advised of which services are affected, the likely severity and duration of impact,

etc.)

Real time information systems may also feed systems which are covered in the following sections:

Section 17.12, Passenger journey planning (immediate-use journey plans will usually need to take current service operations into account, rather than just schedules)

See also section 22 on travel information and section 18 on railway traffic information.

17.15.5 Legislation & Regulations

For real time information provision, the principal relevant European legislation is Delegated Regulation (EU) 2017/1926 “Provision of EU-wide multimodal travel information services”. This states that, where a Member State has decided to provide the “dynamic” information through the National Access Point:

… transport operators, infrastructure managers or transport on demand service providers shall use…SIRI CEN TS 15531 and subsequent versions, technical documents defined in Regulation (EU) No 454/2011 or any machine-readable format fully compatible and interoperable with those standards or technical documents.

“Dynamic data” is defined to include, inter alia, “disruption”, “real-time status information — delays, cancellations, guaranteed connections monitoring”, “status of access node features” and “passing times, trip plans and auxiliary information”.

In terms of presentation to passengers, there is widespread legislation that requires certain kind of information service to ensure accessibility by passengers with disabilities (for example, visually impaired people need audio outputs, while wheelchair users and some other groups may struggle to read displays that are too high). However the specific technical means by which these outcomes are delivered is not currently subject to European regulation.

National and local regulatory policy may vary.

PT 17.14Bookings/reservations

PT 17.15Real time information

PT 17.16Ticket issue/validation

17.16 Ticket issue and validation

17.16.1 Purpose

The purpose of this functional area is to provide travellers with secure and mutually verifiable tokens that give them the right to utilise one or more specific public transport services.

Ticketing is not always required in a public transport system. Clearly, if the service is provided universally with free access, there is no need for a token to embody travel rights. More subtly, a ticket is not required if either the operator or the passenger trusts the other party sufficiently that it is willing to have no means of verification. Account-based systems (see section 17.17) come close to this: a passenger identifies himself/herself as someone with a valid account in order to allowed to take a journey, and the record of the journey is held only within the operator’s systems.

NOTE: Season tickets (despite the name) are closer to accounts, and account identifiers, than to the kind of specific-journey ticket that is the main focus of this section.

However, much public transport does require such a token. Where there is a cost involved – as there usually is – the ticket records this cost, and the appropriate fare is usually collected from the traveller by a suitable financial transaction in parallel.

“Validation” is a complex area. Generally it means ensuring that the person travelling is the person with the ticket, but this has at least three possible interpretations:

In some services a ticket needs to be “validated” prior to use – although this is often rather the activation of a ticket, which has been (validly) issued for a specific journey but requires the passenger to determine just the time of validity.
A separate role is admission, whether through a ticket gate or past a human officer, to the vehicles delivering public transport services.
Finally, there is the function of ticket inspection, in which a human inspector will check that each passenger on a service vehicle is in possession of a ticket which justifies them being on that service.

17.16.2 Actors

Historically, ticket issue and validation have been a direct, transactional relationship between public transport operator and passenger. This is still a widely-followed paradigm. However, more recent public transport business models have allowed this to be somewhat dispersed.

Among such approaches, the commonest is the case where a third party is granted the authority to issue tickets on behalf of the operator. The ticket issuing body usually then also collects fare payments. The relationship between ticket issuer and operator is contractual: the ticket issuer is given rules to follow (e.g. capacity limits) by the operator: then it tells the operator what tickets have been issued, and (contemporaneously or subsequently) sends fare receipts.

A third-party ticket issuer may operate on behalf of one or many operators. In some cases, regulation obliges operators to allow specific third-party ticket issuers.

A third-party ticket issuer may create its own retail offers which incorporate public transport tickets; so long as the operator understands the ticket and agrees to the amount payable by the third party as a “proxy fare”.

A specific case is the issue by the third party of multi-operator tickets, which may include a price mark-up to recognise the value of convenience for the passenger. Multi-operator tickets may be:

Single-leg, but with the passenger able to take a service from a choice of operators
Multi-leg, with each leg provided by a specified operator
Multi-leg, with some legs provided by a choice of operators
End-to-end, with the journey route, mode(s) and/or timing left to the passenger’s discretion within a “permitted” basket of services

Public transport authorities often function as ticketing third parties.

NOTE: The more complex scenarios start to become recognisable as MaaS operations.

A second role shift is where admission is the task of a third party. This usually the case where:

Stop/station infrastructure is managed by a different entity from the public transport vehicles
There are active infrastructure checks, including barriers, that the passenger needs to pass prior to boarding

While this is more common in the rail sector (as well as air, etc.), it can also occur at places such as city-run central bus stations.

The third role shift is when a third party is responsible for ticket inspection. This is less common, and tends to be a simple contracted service between operator and inspection agents.

17.16.3 System context

Ticketing and validation is arguably the most critical single function in a public transport system, since it embodies the contract between provider and consumer. Ticketing systems and processes have to deal with information that is binding, often linked to financial exchange, and sometimes linked to personal data, and are therefore hedged about with security, reliability, accountability and other considerations.

The systems environment for ticketing is partly dependent on the organisational structure, since there is an obvious need to ensure that the operator’s systems can interwork with any third party systems involved.

The other main determining factor is the physical nature of the “ticket” as issued. From an operator’s perspective, the principal token is a central database record; from a passenger’s perspective, it may be a paper product, a smart card, an email with an image, or any one of a number of other forms. The engineering of these individual products is highly complex and variable.

The figure below indicates the (logical) systems involved in the operation of ticketing and validation.

Figure 17.9: systems context for ticket issue and validation

For many purposes, this model is over-complex and abstract. A ticket machine for bus or tram includes journey planner, contract and token issue all at once. However, in other circumstances, the handover from journey planning to contract creation is far from trivial.

The complexity of ticketing as a concept and as a practice is yet further exacerbated when operators have to work in an environment with multiple ticket formats, ticket types, and ticket issuers, all in a highly regulated space.

17.16.4 Related standards

Standards for ticketing apply at multiple levels. As a rule, the more “electronic” the ticket format is – that is, the more the issue of a passenger token is achieved through an issuer’s system interacting with a passenger’s own device or application – the more likely it is that the fare settlement process (see section 17.17) will be closely entangled with ticket issue. There are several European and international standards that describe electronic interfaces and cover, to some extent, both ticketing and fare collection.

The following standards are architectural in nature and cover all or most technical approaches to ticketing:

EN 12896-5:2019: Public transport - Reference data model - Part 5: Fare management

EN ISO 24014-1:2021: Public transport - Interoperable fare management system - Part 1: Architecture

CEN ISO TR 24014-2:2013: Public transport - Interoperable fare management system - Part 2: Business practices

CEN ISO TR 24014-3:2013: Public transport - Interoperable fare management system - Part 3: Complementary concepts to Part 1 for multi-application media

The following standards focus more specifically on the nature of electronic interfaces, specifically in the case of physically close passenger devices and ticketing systems:

CEN TS 16794-1:2019: Public transport - Communication between contactless readers and fare media - Part 1: Implementation requirements for ISO/IEC 14443

CEN TS 16794-2:2019: Public transport - Communication between contactless readers and fare media - Part 2: Test plan for ISO/IEC 14443

NOTE: The ISO/IEC 14443 series of standards provides detailed specifications for smartcards in general. CEN/TS 16794 provides a contextual implementation for the transport domain.

CEN TR 17311:2019: Public transport - Interoperable fare management system - Bluetooth low energy ticketing use cases and guidelines

ISO AWI TR 20527: Intelligent transport systems — Interoperability between IFM systems and NFC mobile devices

EN 1545-1:2015 Identification card systems - Surface transport applications - Part 1: Elementary data types, general code lists and general data elements

EN 1545-2:2015 Identification card systems - Surface transport applications - Part 2: Transport and travel payment related data elements and code lists

NOTE: There are many more smartcard standards, but most of these are general-purpose (regarding physical format, electrical properties etc.). While these are not specifically identified in this document, they are explicitly referenced in some of the standards cited here.

More generally, the following smartcard standards are not specifically aimed at transport

EN 1332-1:2009 Identification card systems - Human-machine interface - Part 1: Design principles for the user interface

EN 15320:2007: Identification card systems - Surface transport applications - Interoperable public transport applications – Framework

Industry practices (notably, on the format of paper tickets, including print-at-home tickets) have been created internationally for the air travel context, and to an extent in the (international) rail context. The following standard is helpful in this area:

CEN TS 16406:2013: Intelligent transport systems - Public transport - Indirect Fulfilment for Rail

This is, however, unlikely to be relevant to a lot of local public transport (bus, tram, metro, etc.).

Other standards relevant to ticketing may be set nationally or as (national or international) industry standards, for example the physical format and layout of paper tickets, the coding of magnetic strip data, etc. For smartcard and other electronic representation of ticket types, see for instance the work of Calypso [Bibliography], VDV [Bibliography] and ITSO [Bibliography]

Ticketing links closely with the public transport functions described in the following other sections:

Section 17.12, Passenger journey planning (required, in some form, for the content of a contract to be agreed – although this will often be done though a simple passenger selection rather than a complex independent planning system)
Section 17.14, Passenger bookings and reservations (these may embed ticket issue systems)
Section 17.17, Fare collection and account management (ticket issue implies the need to either to collect a fare or to register a journey on an account for alter settlement)
Section 17.18, Incident management (the contractual validity of a ticket, as recognised by admission and inspection systems, may need to be changed in the event of an incident – this may be subject to corporate policy and/or regulatory control)

See also section 8 on communications, especially with regard to communications security.

17.16.5 Legislation & Regulations

There is no European legislation that requires tickets to be issued and validated in any specific technical way.

However, European and/or national regulation may affect the way in which specific ticketing approaches are used, either commercially or technically (for example, through GDPR considerations). It is beyond the scope of this document to address these issues, however.

17.17 Fare collection and account management

17.17.1 Purpose

The purpose of this functional area is to collect payment for travel services provided.

This assumes that the basis for payment has been agreed between the service provider and the passenger. There are two general options:

Identification-free travel: these involve anonymous journeys, taken on demand and charged immediately. By their nature the contractual form and basis for charging is single journey and minor variants to it; the ticket is the form of contract.
Identification-based travel: these involve journeys, taken by a specific person who has an external contractual relationship with the service provider. The contractual form and basis for charging can be more complex in this case and is often account-based.

NOTE: Identification-free travel does not preclude understanding of some aspects of the passenger, for example that he/she is a child, or disabled, or holds the return potion of a previously-issued return ticket.

With identification-free travel, settlement is sought at the point of ticket issue. With identification-based travel, settlement need not be contemporaneous with the journey and may be sought in advance or in arrears. In this latter case, the passenger will be presented with an account statement based on the commercial agreement between them, which may or may not need to itemise specific journeys taken.

17.17.2 Actors

This function involves the passenger (or someone acting for him/her) and travel service provider (which may be a public transport operator or an indirect retailer). Where passenger travel is retailed through a third party, there will also be a settlement system between that party and the operator fulfilling the journey.

Indirect retailers can, in principle, form networks, so that payment passes through multiple third parties between passenger and operator.

Note too that in some business models, operators may not need to know who, or even how many, passengers have used their service. For example, a public authority could agree a cost-based contract for a specific set of vehicles, routes and timings with an operator, whose only task is to run those services.

Figure 17.10: actors for fare collection and account management

17.17.3 System context

From the transport context, the transaction of fare collection is relatively straightforward:

the majority of the complexity is passed over to the financial services domain, which deals with matters such as authorising credit cards for individual users and connecting them to banking systems. (The financial system is out of scope of this document.)

Within the transport system, operator systems need to be able to determine whether a passenger has right to a journey by means of checking the payment status of either a ticket or an account identification token.

Where the retail service is ticket-based and settled at the time of ticket issue, the retailer will generally have a point-of-sale terminal. It is a business decision whether to accept particular modes of settlement (cash, credit/debit cards, etc.). Some settlement options do exist, for example through stored value cards or carnets, and since these may be less closely coupled with actual journeys, other settlement options can be used.

Where the retail service is account-based, travel rights are determined using an account-holder identification token (season ticket, travel pass, non-charged credit card, etc.). Payment is then taken against this identity at an appropriate time (for example, at the issue of season ticket, monthly, etc.). A fuller range of settlement options is available, including invoicing, direct debit, etc. On the basis of current status and business rules on credit, the passenger’s identification token will then be flagged as permitting or not permitting travel.

17.17.4 Related standards

Since fare collection is above all a financial transaction, the systems, processes and standards used are almost entirely those determined and managed by the financial sector – for example, the EMV system for bank card payments [Bibliography]. However, these clearly need to be integrated into the transport system; the following specifications and guidance documents provide advice on how to achieve this in various contexts:

EN 12896-5:2019: Public transport - Reference data model - Part 5: Fare management

EN ISO 24014-1:2021: Public transport - Interoperable fare management system - Part 1: Architecture

CEN ISO TR 24014-2:2013: Public transport - Interoperable fare management system - Part 2: Business practices

ISO TR 20526:2017: Account-based ticketing state of the art report

ISO AWI TR 20527: Intelligent transport systems — Interoperability between IFM systems and NFC mobile devices

Of specific direct relevance to fare collection are the systems covered by the following other sections of this document:

Section 17.6, Fare planning (which provides the basis for charging, as presented to the passenger)
Section 17.16, Ticket issue and validation (for the means by which tickets are issued, principally in identification-free travel)

17.17.5 Legislation & Regulations

There is no identified transport-specific European regulation relating to the systems used for fare collection.

There is, of course, extensive regulation that covers both consumer rights/consumer protection (for example, rights to refund), as well as regulation covering financial services (for example, charges made to bank card users by card issuers).

17.18 Incident management

17.18.1 Purpose

The purpose of this functional area is to detect and respond to problems with the planned running of public transport services.

Disruptions are important both for operators (who may incur additional costs) and for passengers (who inevitably incur inconvenience).

Occasionally there may be more serious issue, such as for personal safety of passengers, drivers, and the public at large. While some variation is service is “background” – for example, delays caused by general traffic congestion – in other cases there is an identifiable cause: an incident.

Incidents may originate within the public transport system (e.g. a broken down vehicle) or outside (e.g. flooding). Some categories of incident may be known in advance (e.g. roadworks) and result in temporary rescheduling; others may happen unexpectedly (e.g. road traffic accident). Some categories of incident require the attendance of emergency services (e.g. assault on driver/passenger, fire, or vehicle collision).

The specific goals of incident response depend on the nature of the incident, but can generally be classified as:

Ensuring immediate safety of all those involved
Rectifying the cause of the problem
Getting services back to normal

Incidents known in advance are often “benign” – for example roadworks. This is not always the case, though, since there may be some advance warning of dangerous conditions such as icy roads. For such incidents, planning is possible, though not always as fully and as reliably as under unstressed conditions. Operators will then respond by following the temporary plans.

Unexpected incidents are sometimes benign (at least in respect of potential for continuing danger) – for example, broken down vehicle, absent staff member – but are sometimes dangerous. Where there is a threat to public safety, emergency services will be involved, and will generally take control for a period of time.

Tools available directly to those involved in delivering public transport include:

Incident management systems: technologies that document descriptions of the incident, actions taken and current interventions in force. Such systems will also record, and may include interfaces with, participants involved in managing the incident.
Non-ITS interventions, such as temporarily closing a bus or tram stop with physical barriers, for example to allow repair work to be conducted on the stop infrastructure or to work around roadworks that affect the stop.
Adjustments to routes and service timings to avoid disrupted parts of the network, to manage unexpected changes in supply (for example, loss of vehicles or staff), to manage unexpected changes in demand (for example, if other modes or services are suddenly available), or because emergency services controllers instruct them to do so.
Provision of information to current passengers (for example through at-stop signage or on-vehicle audio announcements) and to potential passengers (for example through websites, journey planners etc.).

17.18.2 Actors

As noted above, the actors involved in incident management depend on the nature and severity of the incident. In addition to public transport operators, they may include indirect public transport authorities responsible for the geographical area and transport mode, emergency services (police, ambulance, fire, etc.), and others.

Associated managers of external information services (such as journey planning systems) and third party retailers (such as MaaS providers and independent ticketing channels) also need to be kept informed, and may also need to take steps (for example in advising new routes, or extending ticket validity).

Passengers are generally consumers of incident information; they may then choose to re-plan their journeys (see section 17.12). They may also act in other ways (for example, as police witnesses) but these roles are outside the ITS context.

Occasionally other important actors may be directly involved in managing the incident, especially for incidents at sensitive locations: site owners (ports and airports, business parks, etc.), security services, etc.

17.18.3 System context

Where incidents are managed wholly via human interaction (for example, viewing CCTV screens and then manually adjusting settings of signs and signals), the system context is straightforward: no specific interconnectivity is required.

The figure below indicates the other case, i.e. where there is a specific system configured for incident management.

Figure 17.11: systems for incident management

17.18.4 Related standards

The primary European standard relevant to incident management systems, from a public transport perspective, is:

Also of relevance is the following European standard; while this is directly aimed at traffic management, it has close connections to incidents as managed by public transport operations:

EN 16157-3:2018: Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 3: Situation Publication

Incident management involves a number of public transport processes and system, including some or all of those covered by the following other sections:

Section 17.2, Route and timetable planning (where incidents are known in advance, temporary route plans and timetables can be created)
Section 17.10, Real time service monitoring (can be the means by which an incident is detected, but is also especially important to track progress of vehicles that are operating in disrupted circumstances)
Section 17.11, Real time routing control (may be necessary as part of the response to an incident, both immediately and throughout the disruption and recovery periods)
Section 17.14, Passenger bookings and reservations (may not be able to be delivered at all, in part, or at the times booked)
Section 17.15, Real time information provision (passengers and other authorities will need to be kept aware of the status of services throughout the disruption, and may benefit from an explanation of the nature of the incident, current response status, etc)
Section 17.16, Ticket issue and validation (ticket validity may need to be extended, e.g. if booked services do not run)
Section 17.17, Fare collection and account management (account charges in particular may need to be modified to account for loss of service)
Section 21 on traffic management and control (most incidents affecting public transport will also affect the road network; a coordinated approach to response and recovery may be helpful)

Section 22 on travel information (especially for generalised incident information, such as upcoming sports events or poor weather)

17.18.5 Legislation & Regulations

For incident management, the principal relevant European legislation is Delegated Regulation (EU) 2017/1926 “Provision of EU-wide multimodal travel information services”. This states that, where a Member State has decided to provide the “dynamic” information through the National Access Point:

“Dynamic data” is defined to include, inter alia, “disruption” and “real-time status information — delays, cancellations, guaranteed connections monitoring”.

17.19 Service performance monitoring

17.19.1 Purpose

The purpose of this functional area is to to monitor the operational performance of a public transport operator over time, with the aim of determining how well it is maintaining punctuality.

Performance monitoring may also address other aspects of service operation, where there are regulatory or contractual obligations on the operator. The outputs of this application area are triggers to investigative and possibly penalty actions by authorities.

Generally, even when certain operator performance levels are mandatory, there is no obligation on public authorities to monitoring actively in particular ways: the extent of, and mechanisms (human and technological) used for, monitoring are therefore discretionary on the part of the transport authority, and can wary widely.

Where specific penalties are imposable for poor performance, there is obviously an enhanced need to obtain robust and evidenced performance data that cannot be easily disputed.

17.19.2 Actors

This function is generally bilateral between public transport authority and public transport operator. Third parties will generally be involved only peripherally, for example to collect data on behalf of one or other of these actors; this does not affect the architecture of systems used to undertake the monitoring, but it can raise some additional contractual issues (for example, how to certify the validity of data provided by the third party).

In cases where the public transport authority is actively involved in delivering public transport operations, performance monitoring may be simply an internal reporting service (i.e. the public transport authority is trusted to monitor and report on its own performance). Again, this does not affect the architecture of systems used.

17.19.3 System context

The systems environment for the traffic signals operation involves a comparison of “required” performance (generally, at minimum, scheduled routes and timetables) against “delivered” performance (obtained during actual operations). Data is taken from the systems used for real time service monitoring (see section 17.10).

Additional contextual information may be drawn in from other systems, especially in order to identify force majeure issues (i.e. where the operator has been unable to deliver the promised level of service, but for reasons that are recognised by regulation or contract to be outside of its control).

Figure 17.12: systems for service performance monitoring

The actions that result from performance monitoring are almost always management actions (for example, financial penalties) that are not connected technically to these systems; “live” connections are unlikely to be practical in most cases. Performance reports are also often published as public information.

17.19.4 Related standards

The area of performance monitoring is highly dependent on local business structures, and not currently subject to specific European standardisation. However, the following document provides useful guidance on how data standards may be used to assist in the process:

CEN TR 17370:2019: Public transport - Operating raw data and statistics exchange

At a more abstract level, the following Transmodel component (which provides, in part, the basis for the document above) is also relevant:

EN 12896-8:2019: Public transport - Reference data model - Part 8: Management information & statistics

Performance monitoring is relevant to the following other sections, which provide additional relevant guidance for specific contexts:

Section 17.2, Route and timetable planning (provides the plans for service operation, which are the basis for much performance monitoring)
Section 17.10, Real time service monitoring (provides the raw input data on vehicle running, which needs to be collated and processed against regulated or contracted performance requirements)
Section 17.11, Real time routing control (records of operational decisions taken, for example to insert new services or to cancel services, are also an important aspect of performance monitoring)
Section 17.13, Meeting passenger demand (more particularly for non-scheduled services, records of delays or failures to meet passenger journey requirements are important)
Section 17.18, Incident management (the existence of unforeseen incidents may provide important contextual information – for example, to mitigate performance levels that would otherwise be considered unsatisfactory)

17.19.5 Legislation & Regulations

There is currently no EU legislation that prescribes how, technically, public transport performance should be monitored or managed.

However, there may be European or national regulation on the expectations of operator performance, and in particular circumstances (i.e. for specific business relationships between public transport authority and public transport operator) these may make particular functional approaches to performance monitoring necessary, which can then have indirect impacts on management systems. For example, if regulation or contract requires operators to meet certain punctuality targets, then there is an implicit need to collect information on how well the operators are meeting these targets.

17.20 Applicable Regulations

The following regulations are cited in this section

Directive 2007/2/EC of the European Parliament and of the Council, 14 March 2007, establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)

Directive 2008/50/EC of the European Parliament and of the Council, 21 May 2008, on ambient air quality and cleaner air for Europe

Directive 2014/30/EU of the European Parliament and of the Council of 26 February 2014 on the harmonisation of the laws of the Member States relating to electromagnetic compatibility

Directive 2010/40/EU, “on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport” (the “ITS Directive”). This Directive has been amended by Decision (EU) 2017/2380 of the European Parliament and of the Council of 12 December 2017 amending Directive 2010/40/EU as regards the period for adopting delegated acts.

COMMISSION REGULATION (EU) No 454/2011 of 5 May 2011 on the technical specification for interoperability relating to the subsystem ‘telematics applications for passenger services’ of the trans-European rail system

Directive 2014/30/EU of the European Parliament and of the Council of 26 February 2014 on the harmonisation of the laws of the Member States relating to electromagnetic compatibility

Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data GDPR.

Delegated Regulation (EU) 2017/1926, “Provision of EU-wide multimodal travel information services”