Establishing the next level of RTPI systems

Posted: 18 August 2008 | Andreas Roller, Product Manager for Real-Time Passenger Information Systems, INIT and David Wright, Team Leader for Transport Systems, Leicester City Council | No comments yet

Real-time Passenger Information Systems (RTPI systems) have been around for almost 15 years…

Zipabout technology

In Europe, hardly any city or traffic zone can afford to ignore the requirements of modern public transport passengers, and the same process takes place nowadays in North America too. These systems have developed from comparable lightweight solutions that were able to consider current delays of the monitored vehicle fleet to powerful, fully integrated networking applications.

RTPI systems are able to derive reliable forecast data from the vehicles during pull-out movements, even before the vehicles have reached their revenue journeys, during layover and dead runs, and they can look in the future to the next trip, also for interlining vehicles. They reach their signs and announcement units by various types of cable-based and wireless communication technologies. They distribute their knowledge to neighbouring systems via standardised communication interfaces. Finally, they allow access to this data via the Internet and via mobile devices for passengers on the move.

RTPI systems are able to derive reliable forecast data from the vehicles during pull-out movements, even before the vehicles have reached their revenue journeys, during layover and dead runs, and they can look in the future to the next trip, also for interlining vehicles. They reach their signs and announcement units by various types of cable-based and wireless communication technologies. They distribute their knowledge to neighbouring systems via standardised communication interfaces. Finally, they allow access to this data via the Internet and via mobile devices for passengers on the move.

Presumably as many articles on RTPI systems have been published as RTPI projects were implemented; probably even more. So what could another article really contribute to this field that has not been printed before?

The answer might be ‘nothing spectacular’. Nevertheless, there are some aspects of RTPI systems that might be worth outlining in more detail, as increased expectations are appearing and new traffic locations with slightly more specific requirements for RTPI are showing up too.

ITCS and dispatching

Operating a public transport service becomes more and more complex – not only because of increasing traffic, but also because of new requirements such as dovetailing different modes of transport. For this complexity and due to the economical pressure to optimise the assignment of vehicles and drivers to the limit, transport services are more vulnerable nowadays. Therefore, disruptions of the service are happening more often and require more tasks to be handled. Consequently, Intermodal Transport Control Systems (ITCS) are becoming highly important as they give dispatchers the necessary support to remove disruptions by means of various dispatching measures.

It is quite evident that a high-capable Real-Time Passenger Information (RTPI) is most needed when disruptions occur to inform the passengers about the existing travel options. To avoid as much extra work as possible, the RTPI system should be integrated into the ITCS and therefore not only recalculate the estimated departure and arrival times but also consider the dispatching measures carried out and their effects on the service. For example, a short turn will lead to several omitted stops and the RTPI system needs to inform the passengers at these stops adequately. Otherwise the system reputation will deteriorate rapidly.

An integrated RTPI system provides three levels of information messages, which are:

  1. Updating of departure and arrival information
  2. Activation of automatic text messages
  3. Definition of individual information messages

Level one considers the effects a dispatching measure carried out has on departures / arrivals at the affected stops. Certain dispatching measures will require the removal of departure information from several or all passenger information signs, whereas others will require to show new departures.

Level two considers the generation of automatic text messages (auto-text messages) – a system which can relieve traffic dispatchers from immediate activities concerning passenger information while carrying out dispatching measures. Therefore, auto-text messages (and/or announcements) are predefined for the different dispatching measures and distributed to all affected stops automatically.

In order to make the automatic passenger information more precise and to reduce the need for manually created individual messages, parameters can be integrated in the auto-text pattern. According to these parameters, the individual information will be collected from the ITCS/RTPI system when a dispatching measure is activated.

Level 3 messages provide passengers with individual information. These can often reflect the current situation much better than auto-messages. In order to allow the control centre staff to handle this in an efficient way, specific requirements are applied to the user interface in the RTPI system.

The information from levels 2 and 3 will be used hierarchically by the ITCS / RTPI system, meaning whenever an individual passenger information message is available this message will be transmitted instead of the autotext. Otherwise the standard message will be displayed or announced.


This integrated approach sounds very easy but requires a lot of intelligence from a suitable RTPI system, as one can see in the following example of the dispatching measure ‘Detour’. Firstly, the detour area needs to be split up into four areas, which are:

  1. Area before the detour starts (original path)
  2. Area of old path at detour (omitted path)
  3. Area of new path at detour (additional path)
  4. Area behind the detour (original path)

Looking at the information requirements for the four areas, it is clear that adjusted information must be given for each area. Consequently, a single auto-text (or voice announcement) is not sufficient to cover all information needs. At least four different auto-messages have to be defined.

To enhance the quality of the automatic passenger information, the following parameters can be integrated into the auto-text and announcement definition:

a) Affected line(s)

b) Start stop of detour

c) End stop of detour

d) Start time of detour

e) End time of detour

If these enhanced auto-messages are not able to answer all questions, passengers might have a need for additional information given by individually created messages. With this logic in place, valuable information can be generated automatically by the RTPI system to support the passenger information aspects of the dispatching measure ‘Detour’.

This example clearly shows that there is no high-quality Real-Time Passenger Information without consideration and integration of dispatching measures. The RTPI system design has to support the immediate and automatic handling of ‘standard’ disturbance situations by updating or removing the departure information, but also by means of automatically generated text messages.

High quality RTPI and a new role: The Information Officer

As we have learned before, Real-Time Passenger Information comes to its best when the traffic is ‘outside’ its normal situation. The more that traffic is disturbed or interrupted, the more helpful and reliable passenger information becomes. As discussed earlier in this article, only the consideration of dispatching measures achieves this reliable information by adjusting the prognosis accordingly and providing the ability to transmit automatically generated information immediately on all affected signs.

However, there is more to consider in the Level 3 of information messages. Individual text messages should be set up on the signs to inform the waiting passengers of further details of the disruption.

The ideal passenger information consists of the following four requirements:

  1. What has happened?
  2. Who is affected?
  3. How long is it going to last?
  4. Are there transport alternatives?

Requirement one informs what really has happened, i.e. what is the current disturbance?

Requirement two tells the passengers if the service they are waiting for is affected. Since disturbances might have effects only on certain lines, others might be mostly or even completely unaffected.

Requirement three gives a rough estimation on how long the disturbance is going to last, at least when an estimation is possible. For example, a blocked street might usually take 20 to 30 minutes until the tow-truck has done its work. Severe weather conditions however, might allow only an estimation of ‘until further notice’ or ‘at least for the next 2 hours’. Even this gives enough information to make a decision whether this is still within the individual acceptable waiting time or whether a taxi or even walking might be preferred.

Requirement four is pointing out possible alternatives within the public transport system. There might be other lines departing from the particular stop which are not affected by the current disruption. Instead, passengers could use the alternative lines with a change at a suitable stop which might bring most of the passengers to their required destination. Also, there might be a stop just around the corner or at least in acceptable walking distance where traffic is not affected. The same goes for other modes of transport, which might be near by and operate under normal conditions, e.g. underground services. Alternatives might also be that extra vehicles are on their way to replace a blocked part of the tram or underground network.

Easy to see information of alternatives is the last and most important piece of information needed in such situations and therefore is highly valued by passengers. Only information on all four levels enables the waiting passenger to make a competent decision for their onward journey.

From the length of explanations above, it is clear that the effort needed to provide competent and reliable information is increasing from requirement to requirement. It is obvious that information of this quality cannot be handled on top of all the other time-consuming tasks a dispatcher has to fulfil. Rather, it needs time, competence and concentration, as well as a profound knowledge of the traffic situation, detailed knowledge of the full public transport network and the ability to formulate the message in a concise style, suitable for the technical equipment available.

This explains why in practice information seldom exceeds requirement one. It is not the lack of will to provide this ‘good stuff’ – it is simply a matter of capacity.

Looking at the classical traffic control centre, we typically find first-class experts in traffic management. Traffic dispatchers have an excellent knowledge of their network and the network of other transport modes in their area. They are trained and highly skilled to handle any traffic disturbance or service disruption and are working hard to provide passengers with the best possible service during the disruption and to regain normal operation. Therefore, many actions may have to be taken. This includes, for example, sending out technicians for broken vehicles or defective infrastructure, sending out extra vehicles for replacement or organising relief services. It is obvious that this often is a challenging full-time job and does not leave the dispatcher the capacity to take care of high-quality passenger information as well.

Considering the activated dispatching measures automatically, modern RTPI systems can assist dispatchers by providing basic information, but are definitely not able to provide information on the aspired four passenger requirements. So there is no way out. If deciding for high-quality passenger information, the public transport company has to react in terms of increasing manpower at the traffic control centre. Finally, this leads to a new role of traffic control centre dispatchers – the information officer.

RTPI system suppliers need to consider this new type of user in their user interface, since their requirements differ from the requirements of the traffic dispatchers: a quick but also detailed overview of all active and planned dispatching measures is required, as well as an overview of the already transmitted auto-text messages. Furthermore, the RTPI system must feature efficient text creation instruments providing a hierarchical repository of predefined phrases. Messages need to be sent out not only to the classic LED signs at the stops, but also to vehicle signs or multimedia screens. Thereby selection criteria like geo-fencing, line or dispatching measures are requested.

The same instruments must also be available for voice announcements at stops or in vehicles.

Bus terminals and transit centres

Looking at the European and North American traffic market, we recognise that there is a renaissance of the classic bus station: nowadays called bus terminal. These buildings are the most modern hubs of public transport and often combine Park & Ride facilities, incorporate different modes of public transport, service and information facilities and retail businesses.

These new bus terminals, or transit centres as they are called in North America, are expansive and complex buildings, partly multi-storey or even underground. The logical consequence is that these terminals need to be highly efficient concerning the usage of their bus gates, due to increasing construction and real estate costs.

Planning such a dense use of the gates has meant that even small disturbances by delayed buses have an impact on the terminal operation. It is very likely that delayed buses will find their original target gate already occupied with the next bus. The late incoming bus must therefore be redirected to another gate.

This dynamic bus gate allocation can be carried out by Terminal Management Systems (TMS) which also cover other important aspects of modern bus terminals. Automatic layover and parking lot management, stationary passenger counting, bus access control and gate verification and electrical gate door control are some of those.

When it comes to passenger information it is obvious, that bus terminals necessitate an integrated Real-Time Passenger Information System to allow passengers to orientate, find their departure gate and to plan the remaining time to departure. An appropriate RTPI system needs to provide specific functionality which differs from the ‘classic’ real-time information applications. The fact that some departures might change their gate ‘last minute’ leaves passengers in the situation that the information just given is not valid any longer. It is therefore necessary to communicate these changes in a clear and conspicuous manner. Audible support by either simple alert tones or more complex automatic voice messages might be considered in this case and should be supported by the TMS.

One unusual aspect of passenger information which is increasingly gaining importance is the so-called ‘Emergency Scenario Handling’ as we are living in times where safety and security issues are required more and more.

In several countries, public buildings like bus terminals are getting building permission only if adequate emergency and rescue plans are incorporated. These evacuation plans consider different emergency scenarios and the appropriate ways to guide people out of the building. A TMS system can vitally support passenger guidance in such emergency situations by sending out predefined text and audio messages to the various electronic signs and PA (public address) system. So the equipment used for ‘ordinary’ real-time passenger information may help in critical situations that hopefully never become reality.


Although Real-Time Passenger Information is a common service in Europe and North America, there are some important new aspects on the agenda. The first is the dovetailing of the RTPI system with the fleet management system of the transport company. As this article has clearly shown, there is no comprehensive and reliable Real-Time Passenger Information without consideration of the dispatching measures taken. Secondly, to implement a true disturbance management, a hierarchical information concept is needed that automatically provides as much detailed information as possible. Therefore, parameters need to be integrated in the auto-messages defined in and generated by the RTPI system. This will disburden dispatchers to a maximum. However, it is obvious that providing high-quality Real-Time Passenger Information is a time-consuming task and thus requires a new kind of dispatcher – the passenger information officer. RTPI providers have to consider their requirements and to provide systems featuring information focused on their needs as well as comfortable text creation instruments. In addition, public transport companies have to provide the necessary and qualified manpower. The third new aspect is the appearance of modern bus terminals, as they call for special requirements regarding RTPI systems. Due to frequent changes in gate allocations, an appropriate RTPI system has to be integrated into the Terminal Management System and must be able to present the information in a suitable way.

The conclusion therefore is that there is a next level of Real-Time Passenger Information, and public transport organisations deciding for an implementation have to create both the technical and organisational preconditions.

The Authors would like to thank Andy Keeling, Director of Regeneration and Culture, Leicester City Council, for his permission to publish this paper.

Related organisations

Related people