Realising the vision

SL had a vision to improve the quality of public transport services in Stockholm by installing a real time passenger information system. Achieving this aim has taken SL on a journey that has resulted in the adoption of a vehicle information system and an Intermodal Transport Control System – offering a flexible base for a range of current and future applications.

AB Storstockholms Lokaltrafik (Greater Stockholm Public Transportation Inc.), better known as SL to most Swedes, manages all public transportation in the greater Stockholm area. This area covers approximately 180km from north to south and 100km from east to west.

Public transportation is very important in this region. The inner city of Stockholm holds about 300,000 inhabitants and even more people work there. 67% of all journeys to and from the inner city are made with SL. The 2.3 million inhabitants in the whole area make on average, 0.86 journeys per day with SL and 1.06 by car. 37% of the daily journeys within the region are done with SL, 46% by car and the rest are made by walking, cycling etc.

The public transport system

In addition, the area SL services’ varies from sparsely populated countryside to the crowded, central part of Stockholm. In order to provide an effective service, covering all areas and coping with the large number of journeys made, a number of different systems are needed. These range from the flexible and wide spread bus system to the high capacity subway system.

Stockholm also has a big archipelago with thousands of islands. To service the larger of these there is an extensive ferry system. During summer approximately 40 ferries service about 300 landing-stages. This traffic is however not managed by SL.

The land based public transport system consists of:

• Subway: 7 lines, 108km, 100 stations with 1,011,000 passengers boarding a wagon each working day
• Commuter train: 3 lines, 200km, 50 stations and 225,000 passengers boarding per day
• Local trains: 8 lines in total, 110km, 98 stations and 116,000 passengers boarding per day
• Bus: 500 lines, around 10,000km and 12,000 stop points and 925,000 passengers boarding per day.

During the morning during rush hour, between 6–9am, there are on average 35 buses starting a new trip each minute. None of these trips are run by employees of SL, as all production of traffic is procured. The process of change from SL running all public transport with its own employees to procuring all of it started in the early 1990’s.

Procuring all traffic

Moving from being an organisation with 13,000 employees (that ran the whole public transport system) to one with just 500 employees (who now purely define and procure public transport) did not happen without a lot of discussion. The debates included questions such as: who should own the buses?; If SL got the best leasing terms, would this mean that there was less for the operators to compete about?; Who would decide on maintenance (as neglected maintenance on a multi-million Euro train wagon would be expensive in the long run)?; What about customer care….who would be responsible to the customer?; As the ticket was paid to SL, should the customer complain to the operator?; Would it be alright for the operator to remove the SL logo from the vehicles and put on their own?

By the end of the 1990’s the situation had evolved to the stage where the responsibility of the operators, as opposed to SL, was stressed. From here the ‘whole journey’ concept was defined. This involved a common ticket system for the whole region where you can start on a bus and continue on the subway with the same ticket. The customer pays SL, and SL decides where to run the lines, what stops to pass, the colour of the vehicles and the time between the trips. It was obvious is that no single operator could be responsible for the whole journey. With this insight followed a new shift and a more stringent division of responsibilities between SL and its operators. This background is important to understand why SL now owns an Intermodal Transport Control System (ITCS) without actually intending to!

Early days

It became clear that SL’s customers were not particularly satisfied with the service that the traffic operators were delivering – and that this was a problem for SL to solve. Dissatisfaction came from a number of areas, including a number of large technical problems that struck one of the subway lines when the signal security system was changed.

A ‘Best in Europe 2005’ contest was took place to see which capital city led the way with regards to providing good public transport services. To be the leading city was, and still is, an ambition for SL. However, the competition also allowed other aims to be defined. One of these was that if it was not possible to always have buses and trains follow the timetable, then it should be possible to inform the customers about this. In the customer surveys that SL conducted, information about traffic disturbances were constantly identified as one of the worst performing areas.

SL had already been experimenting with a Bus Traffic System controlled by two Saab mainframe computers as far back as the early ‘70s. However, they found that this high technology resulted in far too high costs. Perhaps this is why SL was comparably slow to install newer systems since then. In 1990 the first inner city bus line system was installed. This was followed in 1997–2001 when four inner city lines were appointed ‘Stomnät’ lines (frame net). About 120 special articulated inner city buses were equipped with a complete real time passenger information system with internal announcements, traffic signal priority in 150 crossings and real time information in approximately the same number of stops.

Soon after a number of lines outside of the centre of Stockholm were also adopted as Stomnät lines. Buses on these lines are blue opposed to the normal red ones. They are run on heavy lines with a high trip density. They too were equipped with a vehicle computer with internal signs and announcements for next stop information. In general there was, and still is, pressure to better serve the needs of handicapped people travelling on public transport.

Growing plans

Another area that had been under discussion for a number of years was the old and outdated ticket system at SL. It may have been outdated but it was also ingenious and therefore hard to replace. A simple time stamp and other identifying marks on the ticket meant that it was then valid for one hour anywhere on the system. This was accompanied by period tickets that covered the whole region. It may have been ingenious for its time but it was inflexible and did not allow the possibility of developing new fare systems.

So SL decided to introduce a new fare system, ticket machines in every bus, vehicle computers to provide internal stop and destination information, passenger counting system and – soon to be delivered – real time information. With these plans it was easy to see that there would be benefits by coordinating and building a flexible platform for services and future systems rather than letting different projects work problems out on their own.

At the very least, almost all applications in a vehicle need to communicate with surrounding/central systems for configuration and new software versions. Many applications need to know where the bus is, what stop it is at, synchronise time etc. Imagine a number of applications, each with their own GPS receivers and antennas, their own communication network to the central control point (eventually this would be two networks – one for bulk data and one for online messages). And, even worse, each application with its own data provision, supplying basically the same but inconsistent data!

Several systems will also need to communicate with the driver in one way or another. In the buses in Stockholm at least, it was not an easy task to find even one suitable place in front of the driver for the driver interface.

The vehicle information system

So with this in mind a project was started with the goal of procuring a single vehicle information system that could:

• Support the upcoming ticket system with basic services such as data communication and traffic data including fare zones, lines, stop points and time. The same requirements were also needed to support an existing passenger counting system
• Automatically handle information and announcements in the bus about line, destination and stops
• Handle basic functions for real time positioning and prognosis of stop point departures in a central system
• Serve as a platform for future applications.

It became clear that a flexible system like this, where you do not know all future demands, had to be based on a ‘standard’ multi-functional operating system, widely spread and with good number of built in services. The only alternatives were found to be Windows or Linux.

The defined system was not a full fledged real time information system. Only 50 out of the 2,000 vehicles were to be equipped with mobile data communication via GPRS. This was included only to verify the specified functionalities. Furthermore, no interface to the system for dispatchers was included, not even to keep track of vehicle positions.

The main reason for this is to be found in the background described above. Dispatching is clearly a bus operator responsibility and something SL will not interfere with! This opinion at SL management was not easy to change immediately.

Further evolution

A contract was written with the German company Init for delivery of the vehicle information system. The system is a Windows XP based system and thus the project was dubbed ‘BussPC’. Soon after, the system began to evolve. An important decision, to opt for a colour touch-screen as a driver interface, was made. This enabled the flexibility of the platform to be made full use of.

It was necessary to select an operator for the GPRS mobile communication system and procurement started. However, it soon turned out that it was more favourable to exchange the three existing analogue talk radio systems for one common Tetra based talk and data radio system.

The Tetra radio was the first third party software and hardware to be integrated in the BussPC system. Driver login on block is automatically sent to the radio system and when the vehicle changes to a new line the current talk group in the radio is also changed. The driver can make radio calls, adjust the volume and see the signal strength etc. on the touch screen in a look-and-feel interface equal to all other driver functions in the BussPC system.

A number of other applications have or will be integrated:

• The existing automatic passenger counting function can receive and send information. Boarding and alighting passengers are added to the BussPC statistics
• The new ticket system from ERG is also integrated (as described above)
• A camera surveillance system is soon to be installed with 5–6 cameras in every bus. This will also be integrated with bulk data transfer via WLAN, online messages over Tetra, status messages from equipment and more
• The BussPC shows traffic disturbance messages to the passengers from the real time system on the internal roof display
• Third party software receives running GPS coordinates from the BussPC, compares them with road data with speed limit information from the Swedish National Road Administration and delivers the result to be shown to the driver together with proper warnings.

Real time functionality

The time had now come to move from the vision to actually implementing real time functionality! The SL Real Time platform was defined as basically one central database for all traffic systems (whether commuter train, subway, bus etc). Existing systems, as well as new ones, and especially the new bus system, feed this central database.

It was obvious to the technical experts that reliable real time information and information about disturbances and their consequences could not be delivered to customers without using dispatchers to control the system. As the vision became reality this conclusion was also adopted by management and so an ITCS system then had to be included.

Now the technicians were not unanimous on this. Some opted for the new Real Time platform as the most suitable ITCS for buses. However this system would have demanded the development of an over the air protocol for positional messages and all other relevant events between the bus and the central system to be used by two separate companies. One day such a protocol will exist, developed with the help of European standards bodies. Lucky enough Init had already developed an ITCS system. It had even been used in an early version at SL for the four Stomnät lines. This meant that it was now possible to start implementing real time functionality in the project and to integrate the bus driver interface with dispatcher measures and connection protection etc.

At the dispatcher end the Tetra call handling and BussPC systems are integrated. Vehicles can be selected for radio calls or messages in almost any window in the ITCS and can be shown on a map from the call handler. Hand held mobiles with built in GPS are also shown on this map.

As mentioned, the Init system will also deliver information to the forthcoming Real Time System. This includes continuous bus position monitoring as well as departure prognosis for over 10,000 stops and all dispatcher measures that may influence planned traffic in any way. This interface is currently under development.

Time to deliver

The BussPC system together with the central ITCS is now installed and in operation on the whole fleet and at all 25 dispatcher workplaces. Departure prognoses are carried out on the system for all trips and connections are protected whenever data is available. But SL’s goal, to have all customers informed with real time information about traffic disturbances, has still not been met. Two main obstacles can be blamed:

• There are no information channels to the customers available as long as the Real Time system is not ready
• The dispatchers are not actively operating the system, they do not register cancelled trips etc. as there are no agreements between SL and the operators that they should do this.

Some might wonder why a special agreement is needed for the dispatchers to use the ITCS that SL has delivered. Well, of course they do use functions that they find beneficial such as seeing where buses are and to have a current view of some important lines. But to go beyond that, to register events in the system just to give the travellers correct information is a new task which will take time, time they claim they don’t have.

However, I am certain that the operators will, in time, find that more and more of the functions are really useful for them. By being proactive and avoiding problems is cost effective. It is also cost effective to report events, such as a short turn or exchanged vehicle, at the time it happens (with all data automatically at hand) rather than doing it later in an administrative system.

SL now has the job of:

• Defining demands on the bus operators about when and how to execute functions in the ITCS.
• Agree on this with new contract amendments.
• Make the dispatchers understand why it is important to use the system in the intended way.
• Finally, deliver real time information to the customers, all the time and everywhere!

Quality

As repeatedly said, the goal with installing ITCS at SL is to enable the customers to be informed and improve the quality of public transport through better time table adherence, fewer cancelled trips etc. The bus operators’ undertakings in this respect are defined in the current contracts and what the operators do to fulfil these obligations is up to them.

However, it is easy to see that also this will be influenced in the future. A real spin off of the project is the vast amount of data the system produces. Every stay at a stop point is registered with precision in seconds. Follow up can be done in every detail. This is now being slowly discovered at SL and results in increased interest in the statistics. In time this should result in better defined quality levels in the contracts and, above all, a covering follow up on these quality levels. Then, if not before, the bus operators will make use of the ITCS to make money, or at least to minimise loss, as well as improving customer service by informing travellers about any unavoidable traffic delays.