Case Study: Dublin, Ireland

Overview

• Dublin Bus is the publicly-owned operator of the bus network in Dublin. It operates 980 double-deck buses in the city and hinterland of Dublin.
• Dublin Bus has a 5-year Public Service Obligation contract with the National Transport Authority. Performance measures are now linked to PSO payments, and will place increasing pressure on operational quality.
• The company has implemented extensive ITS over the course of two decades. Electronic Ticket Machines were first implemented in 1989 and have provided the backbone of the on-bus intelligent network.
• Vehicle location and voice/data communication capability have been added to provide the platform for a new AVLC system. This is based on a centralized Control Centre that manages services on a real-time basis.
• The AVLC supports real-time passenger information on internet and at bus-stops. The RTPI server and at-stop displays are managed by the city.
• The ITS has been based on the business and operational requirements.
• The AVLC is in its first full year of operation, and has not yielded quantified resource or operational benefits

Scope of the Case Study

This case study deals with the ITS implemented at Dublin Bus, the public bus operator in the metropolitan area of Dublin.

It does not cover the ITS implemented at the rail or tram operators, or any ITS at the small number of other operators of urban bus services, except where this is directly relevant to the ITS implemented at Dublin Bus. Likewise, it does not cover ITS implemented by the city for traffic management or other transportation services, again except where it is relevant to or interfaces with the Dublin Bus ITS (in particular the real-time information)

Due to the central role of the Electronic Ticket Machines in the ITS implemented at Dublin Bus, the technology is covered in this Case Study, insofar as it forms part of the ITS platform and the development/migration path. The fare collection aspects and related functional/technical requirements are covered in the corresponding Case Study in Fare Collection Systems Toolkit.

Context

Dublin has a population of 1.2 million people, the broader metropolitan area population is about 1.6 million people.

Public transport in Dublin consists of the following:

• Urban bus services
• Tram/light rail (“Luas”, 2 lines, implemented in 2005)
• Urban commuter rail (DART, 1 line, renovated in 1984)
• Suburban commuter rail (multiple services sharing the mainline tracks)
• Outer suburban/hinterland bus services

Urban bus is the main means of public transport, providing citywide coverage and carrying more passengers than the other public transport modes combined.

Overall, public transport mode share is low, although this varies greatly across the metropolitan area. Public transport has a relatively high modal share for trips entering the central area during the peak hours (>50% on some corridors). This quickly tapers off with distance from the centre. Private car is the dominant mode outside the centre, and for suburban and peripheral travel. Cycling and walking have low mode shares, despite being favoured in policy terms. Taxis are deregulated, plentiful, and relatively expensive, and have a low share of the travel market.

Plans for Metro and additional LRT/tram are well advanced, although the economic crisis in Ireland has made their implementation uncertain and BRT may be considered as an alternative. These policy issues and investment decisions are likely to be determined in 2011-12, and will have major impact on the modal balance in Dublin.

The primary means of travel demand management is parking control, with strongest parking control in the central areas and in suburban hubs. This is primarily based on dissuasive pricing mechanisms, and to a lesser extent on quantity control.

Institutional Framework

Regulation of Passenger Transport

A major transformation of the Institutional Framework was taken place since late-2009, and it continues to evolve. Previously, all aspects of passenger transport strategy, regulation and financing was with the national Department of Transport. The National Transport Authority (NTA) now takes on many of these roles.

Certain aspects of the framework remain unaltered. All scheduled public bus services require a licence, which is issued by an agency of national government. Regulation continues to be carried out at national level, the local authorities have no statutory role in passenger transport regulation or development. Subsidy is provided to public transport, through the regulator and at the regulator’s discretion.

In December 2009, the National Transport Authority (NTA) was established with an extensive remit for planning, regulation, development, subsidy management and capital investment in public transport. It also was given an extensive land-use planning brief, traffic management powers, and step-in powers in relation to transportation. The NTA is an agency under the governance of the Minister for Transport, who appoints the CEO and the Board members.

The NTA was originally intended to be a transportation authority for the Greater Dublin Area (Act of 2008) but this was amended in 2009 to extend its remit to the national level, and to become the public transport regulator (Act of 2009). On formation, the NTA took over the strategic planning function and staff of the Dublin Transportation Office, and through 2010-11 the Taxi Regulator and Rail Procurement Agency functions and staff have been brought into NTA.

From the outset, NTA took over the oversight and subsidy to the CIE Group companies through new Public Service Obligation (PSO) Contracts. In late-2010, following the development of new guidelines for commercial licensing, NTA became the regulator of commercial bus services, and the relevant functions and staff were transferred from DOT. NTA has, either through its own mandate or through that of the Rail Procurement Agency (RPA), responsibility for all multi-modal transportation services, including ticketing and passenger information.

Public Transport Operations

Coras Iompair Eireann (CIE) is the state-owned public transport company whose business is primarily in the passenger sector (the rail division still has greatly reduced freight activities). It was restructured in 1987 as a group of corporatised companies, such that the Minister for Transport owns the CIE Group, and the CIE Group owns the individual subsidiary companies. Aside from some ancillary businesses such as tours, the CIE Group consists of three main companies:

• Irish Rail (Iarnrod Eireann): has monopoly operation of all mainline and suburban passenger and freight services. It also operates the urban commuter rail services in Dublin.
• Dublin Bus (Bus Atha Cliath): is the dominant operator of urban bus services in the Dublin Metropolitan area
• Bus Eireann: operates inter-urban and regional bus services in competition with private operators, urban bus services in the smaller Irish cities (Cork, Limerick, Galway, Waterford); subsidized local and rural bus services; administers the national schools transport scheme for the Department of Education, in which it contracts out about 70% of the work to private operators and operates the remainder in-house

Until now, the CIE Group organized the internal allocation of subsidies and other finances, and carried out the direct oversight of the companies. With the establishment of the NTA and the PSO Contracts, the governance and institutional arrangements are facing major change, with the individual companies having far more direct accountability to the regulator.

The LUAS tram lines are organized separately under the Rail Procurement Agency, with 10-years operating contracts awarded to Veolia.

Local Authorities

The main metropolitan area of Dublin is covered by four local authorities (Dublin City, Dun Laoghire Rathdown, South Dublin, Fingal), and the extended suburban area extends in three other local authority areas (Kildare, Meath, Wicklow). There is no higher level authority or co-ordination entity for either the four metropolitan authorities or for the greater Dublin area. However, as local authorities in Ireland have never had any mandate for public transport, the lack of such as authority does not have a significant impact on the sector. The one direct area of relevance for the public transport sector is provision of bus priority and traffic management measures. Hitherto, this was done by the individual authorities with some difference in emphasis, but now the Quality Bus Network Office of Dublin City Council deals with bus priority for all of the area. This unit has transferred to the NTA during 2011.

Operator Structure

Dublin Bus is the dominant operator in Dublin. It has had a de facto monopoly of urban bus services in Dublin for over 60 years, reflecting national policy. Dublin Bus is a wholly-owned subsidiary company of the CIE Group, which in turn is a public entity owned by the Minister of Transport.

Over the past decade, some licences have been granted for non-subsidised services from outer suburban areas to the city, and for specialist services such as to the Airport. However, these are negligible in terms of market share of the urban bus business.

Dublin Bus

Dublin Bus operates approximately 200,000 kms. of service per day using a fleet of c. 980 double-deck buses. Dublin Bus did previously operate articulated buses, but these have been phased out for operational reasons. There had also been a major move towards single-deck buses during the 1990’s, but these have also been gradually phased out and the fleet has reverted to double-deck buses.

Dublin Bus operates from seven depots, most of which are in the city and inner suburbs, with the fleet currently allocated as follows:

Clontarf

85 buses

Conyngham Road

98 buses

Summerhill

103 buses

Ringsend

117 buses

Phibsboro

180 Buses

Harristown

183 buses

Donnybrook

214 buses

Total

980 buses

Key metrics for Dublin Bus in 2009 were:

Passengers

128 million

Revenue

€196 million

Costs

€292 million

PSO payments

€83 million

Deficit

€13 million

Dublin Bus have reduced their fleet from over 1100 buses due to two perhaps not unrelated factors, and the downsizing is not yet complete:

• Passenger numbers dropped significantly since 2008 due to the economic crisis, leading to less revenues, bigger deficits. The fleet was reduced in line with the changed demand.
• The Network Direct project restructures the network, simplifying the routes, channeling the services towards the main roads and reducing meandering variants through residential estates.

Dublin Bus currently has a total of 3,685 staff of which operating staff includes:

• 2,545 Drivers
• 139 Supervisors
• 15 Chief Supervisors

Basis of Service/Route Award

There are currently parallel systems for Dublin Bus, which is subject to PSO Contract, and to commercial services.

In December 2009 when the NTA was established and the PSO Contracts introduced, Dublin Bus was granted a PSO Contract covering all of its then-existing route. This was done as a direct award (as permitted under EU regulations) and no part of the Dublin Bus network was made available to competitive processes. The Public Transport Regulation Act of 2009, mandated that it would be done in this way.

The Act also stated that the NTA could, when this first contract is due for renewal (2014), put services to competitive processes. At present it is not known whether the NTA will renew the direct award to Dublin Bus, put all or part of the network to tender, or adopt some other model.

While the award of the global PSO Contract to Dublin Bus has been clear, it is currently unclear how it will work on a route-by-route level, either when Dublin Bus seeks to amend existing routes, or if a new route or route variant is deemed necessary. It is also unclear to what extent NTA will be able to direct Dublin Bus on the services it should operate, or if the planning initiative remains with Dublin Bus.

Commercial Operators

Operators wishing to operate commercial (i.e. non-subsidised) services must apply to NTA (to DOT prior to November 2010) for a relevant licence. The award of a licence and any conditions that may apply are at the discretion of the Minister for Transport. Certain criteria are set out in the relevant legislation, including that there should be a demonstrated need for a service, that the impact on existing licenced services must be taken into account, fitness to operate, etc.

The new guidelines implemented in November 2010 novated the existing Bus Eireann and Dublin Bus commercial route licences, but requires them to apply and be assessed on an equal basis with private operators in all future licence applications. It remains to be seen what impact the new guidelines will have on bus services in the Dublin metropolitan area.

Permits or Contracts

Dublin Bus has a Public Service Obligation (PSO) Contract with the National Transport Authority, which covers all of its current services. This Contract is for a period of 5 years. Whether it will be renewed and, if so on what basis, are currently unclear.

The PSO Contract requires Dublin Bus to provide a specified set of services, to specified performance criteria. In the first year, as the system was being established, the performance criteria were very light and were not linked to payments.

From January 2011, a strengthened set of performance criteria and target values was implemented. Achievement of the performance criteria was linked to payment, up to 10% of the full payment could be withheld for failure to meet the targets.

It is unclear whether targets will remain at these levels for the remainder of the Contract, or whether the performance targets will be progressively increased in subsequent years.

Performance targets that are relevant to the ITS applications include:

• % of planned trips and kilometres operated
• % of trips departing not more than 5 minutes late
• % of destination scrolls set correctly
• participation in the Integrated Ticketing System

The quantum of the payment is not specified in the Contract (at least, not in the version in the public domain), nor is the specific linkage between performance and withheld payments/penalties. It is expected that these matters will be formalized and quantified to a greater extent as both NTA and Dublin Bus gain increased experience in operating through PSO Contracts.

Allocation of Revenue and Cost Risks

Revenue and Cost risks lie with the Operator.

Dublin Bus does receive payments under the PSO Contract (i.e. subsidy). The amount is set by NTA, although the basis for calculating the amount is unclear. Until now, subsidy is provided as a global amount, and is not itemized by route. It remains to be seen whether NTA will seek to move to support defined at route or route cluster level.

It is known that the amount has been reduced in both 2010 and 2011. The review in April 2011 (McCarthy report on State Assets) recommends that subsidy continue to be reduced for all of the CIE companies, it remains to be seen whether this will become Government policy.

Dublin Bus carries all risk for both Revenue and Costs. In some years they have generated a modest surplus after receipt of the subsidy/PSO payments. Following the Irish economic downturn in late-2008, ridership has dropped significantly, and revenue with it, resulting in deficit. The deficit in 2009 was €13 million, or about 4-5% of total costs. Dublin Bus reduced its fleet by about 10%, and continues to restructure its network to improve both operating efficiency and revenue yields.

Tariffs are set by the NTA (formerly by DOT), based on requests from Dublin Bus. In January 2011, a modest tariff increase was approved, but it was about half of what Dublin Bus had requested. It appears to be Government policy to reduce subsidy and contain tariff increases, and use

Motivations to implement ITS

The principal motivations to implement ITS at Dublin Bus have been:

• Develop (and subsequently renew), a secure and effective revenue collection system – this has formed the backbone of the ITS
• Develop enhanced operations management capacity to provide reliable services and deal with disruptions
• Provide communications for staff security
• Provide improved passenger information
• Obtain data for planning, resource optimisation and performance monitoring

A number of significant traffic management measures have been implemented in the last 2-3 years. In addition, about 250 km of bus lanes have been implemented through the Quality Bus Corridors. Collectively, these measures have resolved some of the most serious delays and reduced the amount of lost trips and lost kilometres.

Nonetheless, Dublin Bus currently experiences about 1,700 lost km. per day, about 0.8% of the total planned 200,000 km per day. This is mostly (but not entirely) caused by traffic delays.

In addition to lost trips, timekeeping was problematic and difficult to manage. The scale and unpredictability of traffic delays made it difficult to operate according to schedule, while the lack of knowledge of actual vehicle locations made it difficult to detect drivers leaving ahead of their scheduled time.

A further aspect relates to security of personnel. Assaults and other anti-social behaviour against drivers, as well as anti-social behavior towards another passengers and vandalism, are a continuous source of tension between the bus company and labour unions. The company needed to ensure that it can support its personnel at all times, and the radio system was insufficient for this purpose.

Dublin Bus did have an AVL system, initiated in the 1970’s and operated through to 1994, when the system reached the end of its viable life and was not replaced. The company had been used to an operational situation where there was a lot of knowledge, both real-time and for analysis. When the AVM system was discontinued, it was presumed that a sufficient operational capacity could be maintained with supervisors in the street communicating with each other and the drivers by radio.

After 10 years of this style of operation, it was clear that it was not sufficient. Although the Dispatchers had voice contact with the drivers, they could not get a clear picture of the service and had to trust what the drivers told them. They had become reactive, intervening only when the problems were already there – e.g. ‘the bus is already late, now what do I do about it’ – instead of foreseeing them and regulating the route to avoid the development or spread of delays.

The operations and cost of Inspectors had become very high. They needed to streamline the number of inspectors. They felt that the current arrangement of inspectors was not the most productive.

The company appreciated that it had insufficient information on performance and effectiveness of the bus routes themselves. Information was collected from roadside surveys. While this may have been sufficient for the Memorandum of Understanding with the Department of Transport which was then operating, it would not be sufficient either for an enhanced PSO Contract or for supporting bus priority proposals, for which comprehensive data would be required.

Dublin Bus was also aware that it was well behind DART and Luas (tram) that both already had real-time information displays at stops. This lack was highly visible to the customers, and indeed to decision-takers.

The fare collection system was implemented in 1989-1991 (see separate Fare Collection Case Study for motivation and description). The idea of an AVLC project was under consideration, and was becoming inevitable after the implementation of the Trunked Radio system and the replacement of the ETMs.

It was identified that the AVLC project needed an owner on the corporate/ operations side, and that before moving ahead with the technology, they needed to know what the company needed it to do. An AVLC Project Team was established to define what was needed for an AVLC system, and to formulate specifications. This was done as in interactive process between the Operations Team and the AVLC Team.

Previous experience with ITS

Dublin Bus was one of the pioneer implementers of AVLC systems, referred to as AVM (Automatic Vehicle Monitoring). In the 1970’s, after some years of radio-based route management, it decided to implement automatic vehicle location. The technical system was deployed in a pilot depot in 1977, and following intensive testing and some modifications, was rolled out on a depot by depot basis with completion in 1981.

The technology was based on in-vehicle processing units linked to voice/data radios and to a driver console. Location was based on odometer readings that incremented an initial value set by the driver. All 1,000 vehicles were polled over a 45 second cycle, returning a message that included location and status indicators. Data was processed through a centralized computer system, which hosted both central and depot-based applications. The central system stored the reference route and schedule data, and combined this with the real-time location and status data to provide the information required for the AVM functionality.

Dispatching was organized at depot level. Each of the seven depots had two workstations equipped with display screens and voice radios. The screens allowed the dispatchers to see route schematics that displayed the actual and scheduled positions of all vehicles associated with the route. Alarm messages, requests to speak and other status information were also displayed. As in the current system, drivers could not initiate voice calls, but instead pressed a ‘Request to Speak’ button and the dispatcher would call the driver when appropriate. An Alarm button could override this, in case of emergency.

Operations management procedures advanced rapidly when Dublin Bus was able to switch from radio control to AVM. Initially, the dispatchers were able to focus their attention on vehicles requiring attention. Over time, a corpus of experience was developed, including the ability to ‘read’ the route and to bring a greater degree of anticipation to problem identification and resolution, rather than the previous reactive approach. An anticipatory approach allowed problems to be resolved and dissipated before they became disruptive and required stronger intervention. A range of interventions and response measures was developed, both to maintain the scheduled service and to recover the structure of the service in case of disruption.

The AVM system provided extensive data for service planning, trouble-spot identification, performance monitoring, and incident investigation.

Separately, in 1985-7, a pilot project on traffic signal priority was implemented on the 100 buses from Ringsend depot, and a cluster of 9 junctions in south-west suburbs of Dublin. This was based on infrared transponders installed on the buses, and roadside detectors linked to the traffic signal controllers. The system was then linked to the AVM system to identify the schedule status of the buses, such that on-time and late buses received priority, but buses ahead of schedule did not. This system was successful, but was not extended due to funding issues.

The AVM system had reached the end of its useful life by the early 1990’s. At the time, the company was reorganising itself closer to the UK operator model in anticipation of a liberalization of the market (which did not transpire) and decided not to renew the AVM. The system was shut down in 1994, with just the voice radio functionality being retained until it was replaced in 2001.

While the corporate knowledge of AVM was not lost, in all other respects the AVM terminated completely. It did not provide a logical, network or functional platform for the ITS system described in the next section. Although they overlapped, the Electronic Ticket Machine was designed and implemented independent of the legacy AVM. This was a reasonable approach, as a new AVM system would have been fundamentally different from the original (availability of Windows, improved screen displays, emergence of GPS, move away from solid-state technology).

Applications for which ITS is currently used at Dublin Bus

ITS at Dublin Bus has been deployed and enhanced over an extended period, in most cases building on the strengths of previous implementations.

Overview of ITS deployment at Dublin Bus

The deployment path of ITS systems at Dublin Bus is summarized as follows:

1989

Electronic Ticket Machines

1990-1

Magnetic Card Readers

1995

Autofare

1999

Electronic Destination Scroll

2001

Trunked Radio System

2005

Replacement Electronic Ticket Machines

2008

Smart Card System and Readers

2009

Radio system upgrade

2010

AVL and Control Centre

2011

Real-Time Passenger Information (RTPI)

2011

Integrated ticketing

The ETM was the first piece of ITS. Of greatest significance for subsequent ITS deployment, it used a network approach on the vehicle, whereby the ETM acts as the focal point for peripheral devices (e.g. card readers) with which it can communicate, share commands and receive data for storage. This network approach provides the backbone for most of what has been done since.

The ETM has two distinct aspects, which provided the twin platforms of operational/data generating devices, and back-office/data analysis systems :

• Cash receipts and sales management
• Data generation, understanding of the business

The ETMs were implemented in 1989, and Magnetic Card Validators (MCV) were implemented in 1990-1. These MCVs were connected to the ETMs by the RS485 network, received initiation and reference data from the ETMs, and passed their transaction data back to the ETMs for storage and subsequent transfer to the company’s data systems. While the implemented configuration was one MCV per bus, the capability was there to host multiple MCVs on each vehicle.

The Autofare system was implemented in 1995. Drivers no longer handled any cash or gave change. Customers purchasing a ticket on board placed sufficient cash in the autofare device, the driver issued a ticket from the ETM for the requested fare, and if the cash tendered exceeds the fare, a supplementary receipt is also printed from the ETM for the difference. When the tickets are issued, the cash drops into a safe beneath.

While the Autofare achieved is primary function, it had multiple issues:

• Very high back-office burden – removal of safes every day, handling the safes, transfer of safes and money, safe management and reconciliation
• Cash reconciliation and accountability, since multiple drivers may be assigned to a bus during the day, and hence associated with the takings in the individual safe
• Limited integration with the ETM

Electronic Destination Scrolls were implemented in 1999. This was a standalone system, with no link to the ETM. The information was set by the driver, using an interface inside the cab.

Radio System

By the late-1990’s, the legacy radio system (dating from the original AVM era) was still functional but had inadequacies. It operated on open channel, there were black stops, audio quality was inadequate, and the number of channels and their capacity were limited. Each depot was assigned its own radio channel for voice communication and broadcast from a mast at the depot. Radios were assigned to the depot and set to the specific voice channels. (In the original AVM system, data was handled through a separate common channel).

It was decided to implement a Trunked Radio System, broadly similar to mobile phone. This gives call privacy, the dispatcher controls the radio exchanges, calls the drivers individually, the drivers cannot directly initiate calls but must request to speak and await the dispatcher contacting them. Group calls can also be made. An emergency facility is available which overrides and allows the driver to communicate directly.

The radio equipment was no longer limited to specific channels, and hence no longer limited to a specific depot. Radios are now interchangeable across depots and routes, and are simply assigned within the system to whichever depot and vehicle they are installed.

The radios are integrated with the ETMs through the RS485 network hosted by the ETM. As far as the ETM is concerned, the radio is just another device on the network with which specific functions and data exchanges take place.

The radio does not have its own dedicated keypad for data entry. As the driver already signs on/off through the ETM, and the ETM already hosts the fleet ID, route and duty data, this is exchanged with the radio.

At the start of the radio project, there was dialogue about whether to go with digital (Tetra) or analog radios. Dublin Bus were not sure how to decide on this, so they left the issue open to the market. They had expected to be offered choices, but in fact only analog radio was offered, so they went with that. It may have been an issue of base stations and that the suppliers did not want to cost of having to invest in additional base stations for a single client. The base station at Phibsboro is on their own mast, with no other tenants. At Naul, they lease space.

The radio system system (Tait) now consisted of in-vehicle radios, in-line Dispatchers, and handheld radios for the Street Supervisors. Change would be required to implement the AVLC.

ETM Replacement Project

Dublin Bus needed to replace their ETMs, both because they had already exceeded their design life, and to increase the functionality and memory / processing power. They also wanted to implement Smart Cards and move away from the magnetic card readers that were also past their design life, but in addition had never been totally satisfactory.

In 2005, the Electronic Ticket Machines were placed with a newer generation of Wayfarer ETMs. The main characteristics are:

• It replicates the functions of the old ETM system, with which everyone was familiar
• The entire fares and routes tables can be held by the ETMs, due to greater memory capacity
• It supports the Integrated Ticketing System – i.e. the ticketing requirements of the scheme supported by the Department of Transport (this was obligatory on Dublin Bus)
• Wireless communications are used for data downloads – this removes the previous requirement for portable data modules which each driver had to bring to the depot for download at the end of his/her shift
• Wireless communication is also used for uploading information and data updates. It is also used for uploading software upgrades, removing the previous requirement to physically change the (E)EPROMs in each ETM every time software was amended.
• Improvements were made to the cash reconciliation facility
• Opportunities were taken for further integration

• A linkage was made with the electronic destination scrolls so they are updated automatically when the driver enters the route details to the ETM at shift/trip start
• An electronic tag was embedded in each farebox safe, holding a unique ID. Records are written from the ETM of shift open/close events. A reader in the cash office downloads the data when the safe is being emptied and the cash counted, so it automatically knows which bus the safe has come from, and which drivers were associated with it for that day.

• A permanent identified of the vehicle is embedded in the ETM tray (permanent fixture on the vehicle). This is transferred to the ETM and from the ETM to any other device that needs it. It means that whenever ETMs are switched they automatically pick up the vehicle number, and in turn are automatically assigned within the system.

Smart Cards were implemented in 2008. Smart Card readers are installed on the buses (one per bus) in parallel with the MCVs. The SCRs are another device on the ETM-hosted RS485 network.

Handheld checking devices were also acquired, primarily for the RPU function.

Currently the MCVs are still in service alongside the SCVs. Existing tickets have been migrated to smart cards. At this stage, about 90% of the prepaid ticket transactions are with smart cards. Magnetic strip tickets are still used for common tickets with Irish Rail and Luas. The MCVs will be phased out soon as the RPA/DOT’s Integrated Ticketing System comes on stream.

The current Dublin Bus ticketing system supports the RPA/DOT’s Integrated Ticketing System. Dublin Bus have received circuit boards and software from the RPA to be fully compatible. They have been testing these during Q1/2011, with successful results.

From Q2/2011, Dublin Bus is expected to accept Stored Value Card.

AVLC

The AVLC was implemented from 2009. This involves real-time tracking of vehicles. Buses are polled on a 20 second cycle. The location data is based on GPS and Odometer. The Odometer provides the primary means of location, with the GPS supplementing it. It seems that they left the option open in the tender process, and this was what the market proposed.

The AVLC has the following features:

• Real-time tracking
• More efficient route control regime
• Facilitates a centralized control room
• Generates comprehensive reports and statistics
• Provides/supports RTPI
• Support traffic signal priority

The driver’s console shows when the vehicle is ahead of schedule, and hence the driver should slow down or wait. It was decided not to show the driver when the bus is behind schedule, or by how much, since they did not want them to drive fast in order to catch up. This was a safety concern.

The implementation presented a number of preparatory challenges:

• Data preparation

• Bus stops: GPS data was required for all 5,000 bus stops. While Dublin Bus knew where their bus stops were, in reality this was quite insufficient for the precise information required by the AVLC. It was necessary to do a full inventory, unique identifier and precise location for every bus stop.
• Journey pattern definition: This required all routes, route variants and special journeys to be defined, as sequences of bus stop links.
• Timetables: The granularity for the timetables within the schedules was insufficient, since it would simply show the bus scheduled to travel at constant speed along the route, and thus be misleading to the dispatcher. It was necessary to make initial estimates of the sectional journey times for all links, and input that for each route (these have subsequently been amended as data comes available from the AVLC in operation).

• Mobile communications: A decision was needed whether to go for a private radio network, GPRS, …
• Provision of RTPI roadside infrastructure: This was overcome as Dublin City Council were assigned the role (by NTA) on behalf of all public transport operators.

The AVLC kit consists of the following equipment:

• Bus radio
• Driver’s console
• GPS unit
• On-board computer
• Wireless LAN router

The GPS, on-board computer and wireless LAN router are provided by INIT and integrated into a 19” rack housed under the stairwell.

The AVLC On-Board Computer links with the ETM via the RS485 network. There are now two focal points in the vehicle:

• The ETM continues in its previous role, and is the focal point for:

• Smart Card Reader(s)
• Magnetic Card Validator
• Autofare and farebox/vault
• Driver’s console for the destination scroll

• The AVLC On-Board Computer is the focal point for:

• Odometer unit
• GPS unit
• Driver’s AVL console
• Wireless LAN router
• In-vehicle passenger information display unit
• Door switch sensor

Both the ETM and the AVLC On-Board Computer are linked directly to the Bus Radio.

The in-vehicle passenger information unit is a single line rolling display that announces information such as the next stop. At present, there are just a few fitted for demonstration purposes. Dublin Bus hopes to make it a standard item (availability of funding is an issue). Door-switch sensors are linked.

Real-Time Passenger Information (RTPI)

The authority/responsibility for RTPI is vested in the National Transport Authority (NTA). The implementation task was given to Dublin City Council (DCC), for a variety of reasons, including that they have the authority for any physical works and cabling on the streets. Also, Department of Transport had some concerns about competition issues if the incumbent operator controlled the RTPI. DOT wanted a platform that would be open to and support multiple Operators, in the event that multiple Operators would be authorized to operate.

DCC host the server that handles the RTPI, and has procured and deployed the at-stop displays. DCC are also responsible for the mapping.

DCC rely on Dublin Bus for the data to support the RTPI. Currently there is no formal agreement or contract, and it depends on a sound working relationship (which does exist). There was much technical discussion in advance and specifications were agreed together. When DCC went to tender for the RTPI system, they already had the Dublin Bus specifications, so there was not any problem of downstream integration. Now that the system is fully bedded in, things may be formalized.

Currently, the system can only process real-time information (forecast arrival times) for about 1,000 stops. They are in the process of changing the structure to support all 5,000 stops.

Back-Office Systems

The AVLC cluster of back-office systems has the AVLC software at the centre, with the Scheduling system and the Bus-Stop Database providing reference data as inputs. The AVLC also receives information from the Radio System.

The AVLC software provides feeds to the traveller information systems. This consists of three strands:

• Dublin City Council’s RTPI and TLP
• NTA’s Journey Planner
• Dublin Bus’ own site http://www.dublinbus.ie

Discussion is ongoing with NTA about provision of SMS-based real-time information.

The second cluster is the Fare Collection systems. The Ticketing and Cash Counting system are the systems that are primary generators/acquirers of information. They provide feeds to the Cash Reconciliation and MIS systems. The Cash Reconciliation system provides feeds to the Accounts system. When the RPA’s Integrated Ticketing System comes onstream, the Ticketing system will provide feeds to a common Reconciliation and Settlement system, which will in turn provide inputs to the Dublin Bus Accounts system.

Communications

Each bus has its own unique IP address.

The AVLC communicates with the DCC/RTPI system by high speed fibre link

Each depot has its own Wireless LAN and a digital link to the AVLC system.

Traffic Signal Priority

At present, there is not a functioning TSP, and there are some challenges to implementing it. Currently there is transfer of the full AVLC data to Dublin City Council’s server, primarily as feed to the RTPI network of at-stop displays.

The data is also fed into their SCATS (adaptive traffic signal control system). Currently, this allows the buses to act as probes, adding to DCC’s real-time and post-event data about travel times. It is not used to give direct TSP, but DCC say that it helps them to rebalance the junction cycle settings better for buses.

The data feed from the AVLC to the DCC system is insufficient to support TSP. Buses are polled at 20 second intervals and there is just one-way transmission from AVLC to DCC. Information at 20 second intervals, even if there are no data transfer delays, is too crude for allocating signal priority.

It is not possible to request additional polls from buses that are approaching a traffic signal where it would seek priority. The polling works on the basis of buses being given a slot within the 20-second block, and then transmitting at 20 second intervals on this synchronized slot. This means that the bus polls automatically, it does not await a request to transmit information (as it did in the old AVM system) and there is no basis to request additional polls. Each time the bus moves out of range of one base station and is picked up by another, it is given a new time slot for transmissions.

Dublin Bus and DCC are testing an alternative technical approach, based on vehicle to roadside unit communication. There is a single test site, to the rear of St. James Hospital. A unit on the vehicle transmits a unidirectional message on a dedicated channel, with low power, and is detected by the roadside unit when it is in range. The message includes the vehicle, route and direction identification.

It remains to be seen whether this form of TSP will be rolled out, as it depends on availability of funds. The roadside units would be done by DCC, as with the RTPI, and they would look after the interface with their own traffic control systems.

CCTV

CCTV feeds from the Dublin City Council Traffic Control Centre have not been provided in the AVLC Control Centre. It was not considered to be so important in the initial stages. It was also felt that if the Dispatchers had the CCTV images available, they would focus more on the images, and insufficiently on the information they were receiving from the AVLC. The latter was important, since they need to appreciate the data and learn how to use it in a proactive way.

That said, DDC’s TCC has a network of c. 140 CCTVs providing excellent coverage of most of the key junctions and streets, and most potential disruptions points for the Dublin Bus network. It is very useful in difficult or disrupted circumstances. Dublin Bus are now interested to make it available to the Dispatchers at the AVLC Control Centre. This is OK in principle with all concerned. Funding had been a problem for the integration, including the provision of a fibre optic link from DCC to the AVLC Control Centre in Broadstone. The funding issue is apparently now resolved and the link is going ahead.

Scheduling system and Interface with the AVLC

Microbus is the scheduling software package. This schedules vehicle and driver resources, and supports crew rostering (note that it is not a route planning tool). Schedules are done semi-manually, in the sense that an initial set of operational hours, frequencies (by time period) and running times (by time period) are set out with an initial cut at the schedule and roster. This is prepared on an Excel spreadsheet, and duties are layered on it to generate an initial timetable and duties. This is then input to Microbus which optimizes it and/or allows some modifications, and exports it to other systems such as rostering and AVLC. It is done in this two-stage way to a large extent because of the complexity of the various rules and agreement about drivers’ hours and conditions.

Microbus could schedule/timetable at stop level, but for practical reasons it is done at stage level. Each point in the coded route has a 6-digit unique identifier. This must be compatible with the bus-stop database, and it must be accurate. The AVLC receives the information from Microbus and the Bus-Stop database, cross-checks, and highlights anomalies. Apparently it cannot specifically identify the anomalies but does indicate where they might be. The inputs are then checked manually and any anomalies found and resolved. When it is verified, they are re-exported and imported to the AVLC as the baseline route, stop, link, timetable, and running time data.

The Network Direct program has been going on in parallel with the AVLC deployment. This involves a major sector-by-sector restructuring of the entire Dublin Bus network, with major changes to routes – e.g. straighter main routes, less route variants, elimination of low-volume/low-frequency spurs.

All of this has required a continuing restructuring of the routes, links, schedules, running times etc., which are the baseline data for the AVLC. In turn, it has put major pressure on the route scheduling capacity. Previously Dublin Bus had 4 permanent schedulers. They have drafted in a further four (total team now 8) which has been essential to support the Microbus work for both Network Review and AVLC.

Other ITS applications

There are currently no in-vehicle condition sensors.

There is no direct linkage between the AVLC and other ITS systems and the maintenance systems.

Operations Management

The primary Operations Management is now carried out through the ITS-supported Control Centre.

A number of functions have been centralized at the Control Centre at the ITS Centre in Broadstone (adjacent to Dublin Bus’ Phibsboro Depot):

• AVLC Control Centre
• Revenue Protection Unit
• Customer Information / Call Centre

Prior to the AVLC project, dispatching had been carried out in the individual depots. This has been the practice in the radio-controlled dispatching in the early-1970’s, in the AVM period of c.1977-1994, and in the post-AVM period.

Since the original AVM was closed in 1994, the dispatchers no longer had real-time location information. When the new radio system was implemented, the dispatchers had radio contact, but had to ask the drivers where they were and rely on what they were being told. As a result, dispatching was a reactive activity with a lot of guesswork.

Prior to the new AVLC, there was a total of 32 Depot Controllers, with each of the 8 depots controlling its own routes. In addition, there are 20 Street Supervisors. These are mostly assigned to morning and evening peaks. They have hand portable radios (and lots of back-up batteries) and have a linkage with the dispatchers.

AVLC – Workstation and Dispatcher Support

All dispatching has now been consolidated in a single central Control Centre. This consist of 5 ‘Pods’, each of which has responsibility for the routes associated with a particular sector of the city. Dispatching control is at the route level rather than area, so the Dispatcher remains in charge of the route even when it is another area. One of the Pods has 4 workstations, the other four Pods have 3 workstations each – 16 in total.

Priority is given to ensuring that buses depart on time, and then to maintain their scheduled progress along the route. Where intervention is required, the priority is to maintain an even headway along the route. This is being instilled in all of the Dispatchers so they are clear in how they should approach the dispatch and problem-solving tasks.

The current system shows all stops to the Controller, and the position of the buses relative to their scheduled position. The Controller can see the driver’s name, to help personalize the dialogue.

There are two main screen displays:

• The first provides an overview of the status of all routes. It uses colour codes to indicate the % of buses that are ahead of time, on time, in minor delay, or in significant delay. This overview is intended to help Dispatchers quickly identify which routes are most in needs of attention.
• The second is the display for the individual routes. It shows all of the bus stops, horizontally in the centre, with buses in one direction shown on the upper part of the screen, buses in the other direction on the lower part of the screen.

The individual buses are shown as a rectangular text box with a number of key data items (board number, …). The depictions of the individual buses are colour-coded to indicate how they are in comparison to their scheduled position.

Individual buses/trips can be tracked, if desired.

Future Direction

There is no obvious barrier to decentralizing the Control Centre at a future stage, if that is desired.

System Integration

There is not a formal data model in Dublin Bus. They have studied the CEN TRANSMODEL, but consider it too detailed for their requirements. They have used some aspects, but at the simpler level. For example, they have used the terminology, which helps in describing their requirements to potential suppliers (who would also be familiar with TRANSMODEL and the terminology from working with other clients).

Rather than establish a comprehensive data model, they focus on the interface between systems without being overly concern with what goes on within the individual systems. This is true for both the ITS devices/systems and the back-office systems.

The interfaces are formalized in the specifications, but on a case-by-case basis. There is not a master structure for the interfaces to ensure they are all consistent.

A number of standards are used where they are deemed relevant and useful. For example:

• SIRI standard is used for the data transfer from the AVLC to the RTPI systems. This is not a CEN or international standard, but is recognized within the industry. It is closely aligned with the German VDV standards, and hence known to European suppliers (INIT, the supplier of the AVLC, is a German company).
• RTIC standards are used for the Traffic Light Priority short-range communication from bus to roadside unit.

There is not a formal System Architecture for Dublin Bus’ ITS and IT systems.

Dublin Bus is not dependent on the continuity of knowledge of a single person. There is a team in place consisting of three full-time persons and supplemented by two other persons during the deployment phase. All specifications and interfaces are fully documented, and there is a change control process in place. Much of the detailed documentation is done by, maintained by, and retained by the suppliers, with whom Dublin Bus have good working relationships.

Platform issues

Dublin Bus states any platform preferences in the procurement documents. For example, they may state that Oracle or Secret Server is the preferred approach. In some cases they may state that something is mandatory, in others that it is preferred and that suppliers should make the case for any alternative approach.

Guidance on such platform issues comes from the Information Services Department (ISD) of the CIE Group, who provide guidance on all IT, platform and infrastructure used by Dublin Bus and the other CIE companies (Irish Rail, Bus Eireann).

Dublin Bus relies on ISD for guidance on these issues, and have a good working relationship with them. They acknowledge that they are quite dependent on this support and that it has become increasingly important due to the increasing complexity of IT platforms.

Management and Oversight of the ITS Systems

All ITS used at Dublin Bus been specified, procured, installed and operated by Dublin Bus.

The National Transport Authority has responsibility for the RTPI and the Integrated Ticketing System. Responsibility for RTPI in the Dublin area, including implementation, has been assigned to Dublin City Council. Responsibility for all aspects of the Integrated Ticketing System has been assigned to the Rail Procurement Agency.

Data generation and acquisition for RTPI are performed by Dublin Bus, and the data is transferred to the DCC RTPI server. Dublin Bus have specified, procured, installed and operated their own Fare Collection systems, but are required to be compliant with the RPA’s Integrated Ticketing System (see Fare Collection Case Study for description).

All operations management and control is carried out internally by Dublin Bus. There is no hierarchical structure involving either the transport authority or other operators.

The only outsourced ITS-related activities are support and maintenance (see below).

Service Level standards for the ITS applications

Technical performance levels are specified in the supply and maintenance agreements. This data has not been made available for the Case Study

Implementation and Operational Challenges

Training and Mentoring

It was necessary to develop the PC skills of those who would be the dispatchers of the AVLC. These skills were lacking, and City of Dublin VEC were brought in to assist with both basic PC/keyboard skills, and with processes such as CCTV requests, reporting, managing files and folders, etc.

A mentoring process was also put in place.

Dispatchers were trained in making safety announcements.

Engineering staff were also given training. Each depot sent representatives to the Control Centre to understand what happens there, why properly functioning equipment is important, and to interrelate with the Control Centre staff.

About 10 drivers per day are brought to the Control Centre as part of their ongoing CPC training courses. This builds their understanding of the Control Centre – which they would never see otherwise, since it is not attached to any depot.

Support Activities to getting started

For all of the routes, safe locations were identified for short layovers – i.e. where the bus can be asked to hold for a few minutes if it is moving ahead of time or the intervals need to be regulated. These have been identified, listed, and form part of the toolbox for the Dispatchers.

One of the more senior dispatchers has been assigned full time to the Dublin City Traffic Control Centre. He deals both with daily issues that arise, and the planning for how to manage or divert the bus services for specific events.

Relationships have also been built with the Traffic Police.

The Bus Stop Database needed to be completed, and assured to be accurate.

For the AVLC and RTPI, intermediate sectional times were required. The AVL team equipped some buses which they rotated across routes and used as probes, gathering a preliminary set of sectional times which used to populate the various systems. This either has been or will be updated based on the live AVLC data.

Transition

While the AVLC equipment was being rolled out throughout the fleet, the AVLC operation commenced on a vanguard route (route 123). One of the dispatchers (a former driver himself) was given the lead role from the dispatcher side, which included establishing the dispatcher practices.

For the first two months, he would call the drivers to tell them their actual departure time from the terminus (especially if they left early) based on the real-time information coming to him from the AVLC. At this stage, he was not trying to control their operations, but simply reinforce that they were visible to him. Although the drivers said they had not yet received instruction from their Unions to co-operate, the point was effectively made and drivers began to depart at the correct times.

This helped to establish some ground rules, without having to go through a process of confrontation and dispute. Most drivers were happy to have it work properly, since drivers who departed early were causing problems for everyone.

Deployment

Dispatchers were moved to the Control Centre in November 2009, ahead of the AVLC operational deployment (all the system was in the process of installation). The global number of inspectors was reduced from 150 to 135.

All of the AVLC equipment is deployed. The various routes have been brought onto the AVLC during 2010 and 2011. The last few routes went live in April 2011, thus completing the AVLC operational system.

Deployment Challenge

The ITS – and the AVLC in particular – impacts on the standard operating procedures. As a result, it usually needs to be done fleetwide. Dublin Bus consider that cannot be done piecemeal where some routes are on the system and others not.

This gives a logistical challenge where installation must be done on 1,000 buses and 2,500 drivers need training and to consistently use new or adapted procedures.

This required a lot of planning, resource and management commitment. Nonetheless, it did not produce any significant obstacles or challenge beyond the resource and time involved.

Reports and analysis

The database used by Dublin Bus is Mobile Statistics. The challenge is how to interrogate it so that they get meaningful reports.

• They can set up daily, weekly, bi-weekly, monthly reports, etc.
• They are trying to get to a point where managers can get the ‘heads-up’ reports they need to draw their attention to where there may be problems, where they need to look more closely.
• They should then be able to go into more detail – e.g. track a route for a period of time, track an individual trip/bus, examine a specific route section

A large part of what has been done in the initial months (note that the system is still in the first year of live operation at time of writing) has been cleaning of data, report structures, anomalies, etc.

Comparison of the AVLC data and what is actually happening on the street is a necessary stage in the first year, since it cannot be presumed that the AVLC is 100% accurate. They have found very good correlation, albeit with some anomalies. The first pass of these anomalies have found some drivers not initiating things correctly, perhaps also some equipment not calibrated correctly, these will be normalized quite quickly. There are still some items that cannot be readily explained, they are investigating, teasing it out, figure out what this means and if resolutions can be found, or it there will always be some quirks within the system.

One area that is already proving useful is review of the adequacy of running times for the various routes – especially in the context of Network Direct where ongoing restructuring is taking place. When the Unions come in and complain about running time, they can generate the data and together examine whether in fact there is any problem, if so, whether it is at specific times of day, days of week, occasional or frequent, etc. The aspect requiring modification, if any, can be determined from the data and the running time adjusted within the schedule.

Two issues are currently receiving attention:

• How to measure route performance
• How to measure effectiveness of Dispatchers

Two people are being trained in Mobile Statistics to develop the report and analysis aspects. They are working with the Managers to figure how the reports could be better, and better aligned with what they need.

Dublin Bus now operates under a formal PSO Contract to the NTA (the PSO Contracts were introduced in December 2009 when the NTA was established). For the first year, the parameters and targets were light, and not linked to payments. From January 2011, NTA has made the targets tougher, and up to 10% of the amount payable under the PSO Contract could be lost if the performance targets are not met. It is probably that these targets will become increasingly tough, and that the payment linkage will become very important. In that case, it will also become increasingly important both to be able to deliver the required level of reliability/service quality and to track and analyse performance and problem areas.

External Advice

Generally, Dublin Bus have not engaged external advice (other than the CIE Group for ISD issues, mentioned above). They have built up a lot of experience themselves over two decades and have a small, full-time team in place.

There are two cases where they did engage external expertise:

• Trunk Radio system
• Smart specification

In both cases, they engaged Consultants (not suppliers). This was primarily because they felt they did not have enough strength in the area to be able to properly describe what they wanted for the procurement. Otherwise they would have done it themselves.

Since the end of the EU projects in the 1990’s (GAUDI, ANTARES, CONCERT), Dublin Bus has not been involved in any other EU collaborative projects or knowledge acquiring/sharing actions.

ITS Maintenance and Support

Dublin Bus has established supply, maintenance and support agreements with the suppliers of the ITS equipment and systems. This includes the regular maintenance and bi-annual site inspections.

There are currently no 3rd party maintenance contractors. All maintenance is done either by the suppliers or by their appointed agents (who must be approved by Dublin Bus).

Dublin Bus recommends this approach and have found it invaluable, although it does come at a price. At this stage, Dublin Bus have worked with the radio and fare collection system supplier for many years. The systems always need adjustment, enhancements and upgrades, and a good working relationship allows this to be done without fuss or having to launch new procurements – it can be done as a request or if necessary as a variation order. Probably more importantly, their suppliers understand the systems and their history.

Dublin Bus considers that it becomes particularly important where there is integration between systems, and either new functionality must be added or problems identified and resolved. As they need to work with two or more suppliers, it is essential that all parties have good working relationships with each other, and are interested to find a good solution.

Another advantage is that their radio supplier (Tait) and AVLC supplier (INIT) co-operate on other projects. On one hand, it means that they are familiar with each other’s systems. On the other, it means that they are developing extended functionality, enhancements and bug-fixes for other Clients. Some of these enhancements appear in the upgrades that Dublin Bus gets as a matter of course, in other cases it allows the suppliers to respond more quickly to requests from Dublin Bus.

Capital Costs of the ITS

Detailed costs are not available (known to Dublin Bus, but not in the public domain). The total costs for the ITS – radio, AVLC, back-office systems – is in the €8-9 million range for 1,000 buses.

Dublin Bus would not have been in a position to make these investments without the financial support from Department of Transport, Transport 21 and the NTA.

Operating Costs of the ITS

This data is not in the public domain and has not been made available.

Revenue Generated by or through the ITS system

There are no incomes generated by the ITS systems.

Benefits arising from the ITS systems at PRTC

The achieved/perceived benefits of the ITS investments have been:

• Reliability of service
• Reduction/virtual elimination of buses departing early from termini
• Data on service performance
• More precise/appropriate scheduling (sectional journey times, variances)
• Use of speed/delay data to identify delay points and supporting case for traffic management improvements or bus priority
• Data to support RTPI

Benefits of the ITS systems have not been quantified, and it does not appear that it was felt necessary to do so.

The ETMs were a straight replacement for the previous, life-expired units. It simply was not an option to avoid replacement, as revenue collection and protection is a core function and the ETMs have been deemed highly successful. Similarly, the Smart Card Readers, even though new, are replacing the Magnetic Card Readers which were now almost a decade past their design life, and it is inconceivable that there would be no method of handling pre-paid ticketing.

The radios were seen as essential for security (this has long been an issue with the Unions, due to a serious problem of assaults on staff) and again it is seen as fundamental that buses would operate with radio communication.

The AVLC is somewhat more discretionary. However, as the company was well aware that they did not have proper operations management and control, and were missing out on both RTPI and the data that the AVLC generates, it probably did not need a rigorous business case.

Overall, it would appear that the benefits are seen as self-evident, and that these systems are just basic requirements for bus operations.

Dublin Bus notes that some benefits take many years to come through, and would not appear on a contemporary benefit assessment. For example:

• the original ETM in 1989 established the RS485 network on the vehicle. For more than a decade, the MCV was the only device on the network, and it could have been argued that a network was not necessary. However, the Network is now invaluable, first for the integration with the Radio, then with the SCR and the destination scroll, and now with the AVLC
• the driver sign-on facility was originally used only for the ETM. It now provides the initialization basis for multiple systems
• when the radios were implemented in 2001, the supplier (Tait) happened to be developing a data radio polling application which they included in the system for Dublin Bus. The benefit was only realized some 8 years later when it provided the platform for the AVLC polling and data transfer

To date, at least, the AVLC has not facilitated a reduction in the number of buses required to operate the service, or provided an observed improvement in productivity/efficiency.