08 REAL-TIME PASSENGER INFORMATIONSUPPLEMENT


are, what the congestion situation is, and whether there is any event or decision that is affecting things. Because of this complexity, delivering RTPI


successfully can be tricky. Indeed, there is a sad history of working real-time systems which have


» For over 10 years, RTIG has been developing and publishing open standards and technical architectures for RTPI, and there is now a fairly substantial library of good practice guidance «


had to be shut down, or at least mothballed – sometimes for financial reasons, sometimes for technical reasons. That hasn’t stopped the clamour for it.


David Quarmby CBE, tasked to report to the UK Secretary of State for Transport on ‘The Resilience of England’s Transport Systems in December 2010’, insisted we do more and better: “The rail industry should develop and implement resilient and flexible methods of providing pre-journey and real-time


information to passengers alongside and largely independent of the main customer information systems…Network Rail and the train companies should also embrace the cultural need to ensure such arrangements attract appropriate priority, resourcing and recognition.”


Sir Roy McNulty’s report ‘Realising the Potential of GB Rail’ (May 2011) opened the lid and peeped inside: “...passenger information systems...rely on local information rather than route based data, leading to inaccurate real-time information (particularly during delays)... The solutions proposed for improving passenger information form a check-list for IS across the rail industry...”


Systems... With systems solutions, one often hears the cry: “the technology is fine, it’s the institutional issues that are the problem.” Well, with RTPI that’s not quite true: certainly institutional issues abound, but technology can be a problem too. Sir Roy recognised this and, to his credit, offered some outline solutions: we need “open


and common standards”, we need to “eliminate or reduce manual interfaces”, we need “a streamlined and efficient common technical architecture”, and in particular we should be “connecting the on-board information systems to the track and station architecture.” Those won’t completely solve the problems, but they will make a big difference. For over 10 years, RTIG has been developing


and publishing open standards and technical architectures for RTPI, and there is now a fairly substantial library of good practice guidance. We are currently working closely with the rail industry body, RSSB, and the Future Communications & Positioning Systems Advisory Group, to develop a ‘connected services framework’ for GB Rail. It isn’t going to happen overnight. Even


assuming standards can be developed quickly, and remain robust over time, it takes a while for systems providers to develop compliant products; we then have to wait until the companies involved procure those products, roll them out, and integrate them into their operations. Yes, it can be accelerated, but if the pace is forced too much, costs and risks both rise.


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15