Does franchising mean fragmentation?
Call this a lesson from October 14.
A transportation system is just that — a system. The theory says that for the system to work optimally, there should be as much central control and oversight as possible.
In that aspect, we thus have the Land Transport Operations Centre, somewhere in Singapore. This is supposedly the nerve centre for all land transport operations — playing a supervisory role over the ITS Centre for road-based transport, and the various rail lines. In peacetime, this functions as somewhat of a central clearinghouse for transport information, with its public facing systems being the Datamall API and apps that depend on it, like mytransport.sg.
Personally, though, I’ve more questions than answers on the effectiveness of the LTOC and data especially with the fragmentation we’re seeing in both the rail and bus industry thanks to contracting models. We all know what the government’s goals on data are, which I need not repeat.
Balancing the trapeze rope
Let’s start with buses, since this is a lot more obvious. A lot of money was spent on the Trapeze system to facilitate common fleet management across all operators on contracting packages. In any case, stop right now and read Land Transport Guru’s writeup on how the Trapeze system works if you haven’t already:
We thus know that the Trapeze system is able to provide direct data sources to the folks in LTOC regarding bus service standards. Additionally, the LTG article even discusses the possibility of LTOC to coordinate responses to a given situation following the example of CentreComm in London, such as emergency services involvement and even emergency route diversions.
It may only be a guess on the part of LTG about whether such functions exist, but part of me wonders whether this could have happened on the night of October 14 — that the LTOC swings into action to handle the coordination of bridging bus services. But reading the investigation report that was released, was this even a concern? It appears to me that the thinking went something like “go downstairs to take the bus, we don’t really care whether they exist”.
So perhaps this is another case where they spend millions of dollars to implement the functionality but don’t use it. The question can be asked, though, about the actual logistics of making use of said functionality. What desk at LTOC or even the ITS Centre would be best placed to perform this job, especially if it’s only needed during emergencies?
There’s also questions about the operation of such replacement services. Well, there are apps, and after 2011 they put up signs telling you where you can take replacement buses. But the signs won’t tell you how long to wait for a bus, for one. So perhaps such functionality could be extended to replacement buses as well, especially considering that the route data for planned closures and replacement bus services already exist within the bus network systems — not just Trapeze.
Feeling in the dark
The train system is of course where the most questions lie, but this may well be a question of system architecture and whether the data flows even exist or not, and if not, whether implementing them would be an additional project with millions of dollars needed. Once upon a time I did say that the only thing portable between MRT lines was theoretical knowledge, since each new MRT line is designed with mostly separated communications and control system architectures as part of the New Rail Financing Framework.
Let’s be frank, there aren’t even train timings available on the respective LTA-run apps (and by extension, Datamall). SMRT has theirs through their own SMRTConnect app, but I don’t think anyone wants any more apps than necessary. SBST? Forget it. This pales in comparison to other major world cities that already have such functions, like Tokyo, Hong Kong, London, and even New York, where their antiquated technology only needed a minor update to produce such functionality.
With the current situation it would even be helpful to publish loadings of trains (either real-time or a week’s summary) like what some other transportation providers are doing to help people decide when to travel and thus promote social distancing. None of that is happening apart from a crude line graph from the minister, with such a low resolution it makes it difficult to actually use for good decision making.
And on the Tuas West Extension, where trains run every 15 minutes off-peak (way out of range of “turn up and go”!), a train timing app or even a published paper timetable might even be able to help passengers there avoid waiting around at stations. Of course, without the data flow, someone would have to type out a physical timetable, but that takes manpower. Maybe a bored station manager could oblige us?
However SMRT is doing it is pretty reasonable in itself, and should show that most of the cybersecurity concerns about exposing key train service computers to the internet can be dealt with — not perfectly, but satisfactorily. It’s not like the Datamall API doesn’t know who you are anyway, with a requirement for real-name registration for developers, so most forms of abuse from that vector can be quickly caught too.
It could also be possible that the shared 22kV power networks for the Circle and compass lines being managed from two different places might have made things worse. Since the Circle Line is operating from a backup location due to upgrading works at the original OCC, it’s also possible that the spatial separation may play a role in human factors such as teamwork. Heck, this is why MTR (a unified operation) have all their lines run from a single room. Of course, with multiple operators this may not be feasible, but presumably there’s a role that can be further developed in overarching command and control, such as requesting for additional trains or warning of issues elsewhere on the network.
The tools matter too
For some reason I think a lot of the focus on October 14 lay on the people and the processes, and not necessarily the tools. In a very big change from precedent, the full investigation report on the entire incident was released, but it largely referred to technical causes and not a lot on how on-ground actions were taken during service disruptions.
Whatever was discussed about the passenger experience mainly focused on the decision to detrain passengers from trains. This aside (though I think the CCL detrainment could have been avoided had they waited a few more minutes, leading to an earlier resumption of service), there’s not much feedback on how well the alternative services operated. Of course, with the experience gained from years of planned closures, it could be that the communication regarding the availability of alternative services has been much improved from earlier incidents. At the same time, from people I know who were stuck in the disruption, the sense I get is that the activation of such protocols wasn’t that fast enough.
Another question I’d have is whether scaling up manpower to respond to such a crisis is really the way forward. From what I know, office staff have been called back to act as ushers during the disruption. Is that sustainable? I don’t know, given that the demands of a crisis are going to be much more than in peacetime, but I can’t help but think that customer service robots could be a good idea.
Robots could help the not-so-technologically literate with constant connection to the internet and thus the most updated information on a situation without having to look at a phone (which contingency staff would have to do anyway, or you can do yourself). This could help with getting over some of the communications issues mentioned above. In peacetime, robots could even be deployed at remote farelines, where the PSC is not easily accessible, providing a more visible presence than an intercom built into the ticketing machines.
And, at the end of the day, it would do them well to ensure everything is coming from the same data sources. Of course, I say this without a clear understanding of LTOC’s true capabilities (which presumably remain classified), but if that means money has to be spent to make sure that the LTOC actually has good data fusion abilities to manage a true multimodal response to incidents, and not just different computers at different workstations saying different things, then so be it.
