6 Questions Local Authorities Should Ask Potential RTPI SuppliersThe Trapeze Team | May 11, 2015
Local Authority staff increasingly understand that Real-Time Passenger Information (RTPI) systems are critical to delivering a more comfortable, relaxing and reliable service to public transport users. However, such systems are also inherently complex, often involving multiple stakeholders and requiring delivery expertise across multiple departments, while also working with a variety of data formats across a number of interfaces and platforms. It is therefore important to find a supplier that is right for you – we hope the questions below will help!
1. Is this a cloud system?
‘True’ cloud (browser-based) systems offer various advantages, including greater security controls; potentially improved responsiveness and performance; and a greater ease of use by workers. Furthermore, such systems reduce the need for extensive ICT involvement and overheads, thereby delivering significant cost savings.
It is also worth considering the additional benefits of remote working, which can reduce office space costs and increase worker productivity; while also reducing levels of sick leave and staff turnover.
2. Can we share data with our partners?
Bus services don’t stop at borders; all authorities manage cross boundary services and have a requirement to provide users with accurate and useful information. As a Local Authority it makes sense that the more data you can see, the more you can improve the quality and usefulness of your outputs.
It is therefore important to consider how your RTPI system can facilitate the sharing of data with other authorities and bus operator partners. Your objective here is to share data safely, securely and effectively via a single common platform which can be accessed by anyone – while retaining the ability to control who can see what.
A good example might be the sharing of a common map and NaPTAN stops data, which could be viewed by anyone, including operators – thereby improving consistency across the region.
In this instance – as in others where a data sharing service is offered – the clearest benefit is the reduced overhead of managing cross-boundary services, where data need only be entered once. There is of course also significant potential for improvements in data cleanliness.
3. Does your system comply with industry-standard interfaces?
Importing and exporting transport data is time-consuming work: we know importing schedule data alone can take some Local Authorities days at a time. Meanwhile, manually managing data in various formats, and in various industry-standard interfaces, such as TransXChange and ATCO.CIF, increases the potential for invalid data entries and other risks.
If your RTPI supplier’s system works seamlessly with industry standard interfaces – as well as various data formats – it will not only reduce the amount of time importing and exporting data takes; but also help improve data quality.
If your RTPI system is able to receive data from any industry-standard source, it can use this information to automatically populate the transport database, validating schedule files as they are received and rejecting any invalid files.
Furthermore, working in compliance with industry-standard interfaces can help fill any ‘gaps’ in inadequate or incomplete data. For example, by using data from all sources to merge trips from two or more routes into one route where not enough data is contained within a single source (such as CIF data) to adequately merge the routes together.
Of course, this question isn’t really about interface compliance; rather, it is about maximising the potential of these interfaces and using them as a means to increase efficiency and improve the quality of data input and output.
4. Can we use other ‘on bus’ devices and services to provide or improve AVL data?
ETMs are an often overlooked source of valuable Automatic Vehicle Location (AVL) data. But how do you access that data?
RTPI systems can be configured to support the receipt of AVL data through standard interfaces (such as from the ETM using RTIG T-030 for example). Crucial to this is communicating with third party systems, via, for example, CEN SIRI. Having your RTPI supplier implement this setup – and taking responsibility for the configuration and commissioning of all SIRI connections – can help Local Authorities keep a watchful eye on all the vehicles out on their roads in real-time.
A crucial advantage of this is that any unknown vehicles can be flagged as anomalies, which can then be investigated further. What is more, any concerns over ‘clock drift’, or service delays on particular buses can be highlighted through such a central interface, via alerts and warnings.
Once you have the system in place, you can further improve it by including a KPI in the system. This makes it possible to measure time difference between GPS time reported in incoming RTIG messages and Central Server time (i.e. RTIG T030 delivery lag).
5. Could we make use of a common platform for RTPI delivery?
Modern passenger information tools are increasingly attempting to emulate how passengers think, anticipating changing needs throughout a journey. Part of this means understanding how passengers want to consume RTPI data – which may be via the web, a smartphone app, or from an on-street display unit. (Of course, it may also be all three – plus a few extra).
It therefore makes sense to use a common platform or database – which we like to call a ‘Common Work Model’ – to deliver information. Part of such a model might be using the same platform for your RTPI, scheduling, journey planning and other information systems.
Such an approach would ensure minimum data entry and maximum data quality – while also maintaining accurate predictions of arrival/departure times across websites, on-street displays, travel apps and so on.
It is important to not put all your eggs in one basket; but we suggest you do ask your supplier to help you integrate your systems so they are all on a common platform.
6. How can we keep our RTPI consistent and accurate?
Nowhere is the phrase ‘quality; not quantity’ more true than in the realm of passenger information. Providing information to passengers is only worthwhile if it is accurate and can be relied upon consistently. Therefore the quality and reliability of RTPI feeds is critical to both travelers’ and operators’ perceptions of the effectiveness of a RTPI system.
As with any complex system, there is a risk that communications between servers, signs and websites will fail or become overloaded; compromising the consistency of updates and potentially creating a ‘blackout’ of information. This can be mitigated, however, by using robust GPRS communications infrastructure and suitable server hardware and hosting.
A key part of your approach to delivering RTPI should be based around the maintenance of data feeds. It is critical that you ensure adequate maintenance and management of existing connections, as doing so avoids issues occurring overtime that impact data feeds and result in loss of data or reduction in services.
In order to monitor data throughput effectively, it is also important that you are able to detect issues quickly and can flag them to relevant nominated staff. Meanwhile, connection monitoring protects against service abuse where subscribers might inadvertently overload services, potentially denying services to others.
If you are able to maintain the quality of your data and also maintain the consistent delivery of accurate information, you can ensure travelers’ and operators’ perception of your RTPI system are extremely positive.