Thoughts on CBTC’s Future (Updated, With NGTC Conference Video and 1995 Railway Age Reprint)

Dr. Alan Rumsey

Railway Age and Parsons held the 2023 Next-Generation Train Control Conference in Philadelphia on October 26 and 27. Dr. Alan Rumsey, one of the industry’s foremost, widely renowned experts on CBTC (communications-based train control), was a featured presenter. He shared his thoughts and vision on CBTC’s future in this video with Mike Palmer, Parsons Director of Rail Operations and CBTC.

Before we attempt to predict the future of CBTC, I suggest we first look at the origins of moving-block signalling and the evolution of CBTC up to this point in time.

Brief History

In looking at the origins of moving-block, we need to go back at least 50 years. In the 1970s, for example, there was a great deal of academic interest in a futuristic mode of transportation call Personal Rapid Transit (PRT). This transportation concept included very small, fully automated vehicles or pods, operating at very short headways providing a direct, origin-to-destination service on a network of predominantly elevated guideways. You would simply punch in your desired destination, and a vehicle would automatically be dispatched to your location, to whisk you to your destination. Such a transportation mode would obviously have required a very sophisticated control system to not only keep the vehicles safely separated, but also to manage and optimize the routing and merging of vehicles on the network. Specifically, the control system would need to be highly customer-focused, moving individuals, or small groups of people, safely, reliably, and efficiently to their desired destinations.

One concept for achieving this was referred to as the “synchronous moving cell control philosophy” in which vehicles would be assigned to, and controlled to remain in, hypothetical cells or slots moving along the guideways. To physically achieve such a system would have required smart vehicles capable of determining their location with respect to their assigned cell, a smart wayside capable of managing the movement of all the vehicles in the network, and bi-directional communications to link the vehicle and wayside systems. In other words, a PRT system would have required a control system with the characteristics of what today we would describe as CBTC.

If we jump forward a decade to the 1980s, we find that PRT systems were never implemented, at least not at the level initially envisaged, but a somewhat similar control system emerged and was implemented on the SkyTrain in Vancouver. SkyTrain was an Intermediate Capacity Transit System (ICTS). It was also fully automated and consisted of relatively short trains operating at short headways on predominantly elevated guideways. This control system also adopted a “moving-block” control philosophy that required smart trains capable of precisely determining their location with respect to its assigned movement authority, a smart wayside to manage the routing and regulation of the trains, and a bi-directional communications link between the trains and the wayside. This was the first practical implementation of a CBTC system.

One thing I recall from the Vancouver Skytrain days is that the individuals who had the most influence on the requirements for this new control system were not signal engineers, but operations specialists—something I will come back to later.

If we now jump forward another decade to the 1990s, we find that not only was CBTC being applied to new greenfield metros, but existing transit agencies around the world. London, Paris, San Francisco, New York,and Hong Kong, for example, were all starting to take an interest in the moving-block CBTC concept as a means of increasing capacity on their existing rail infrastructure. In 1995, Railway Age and Parsons (or De Leuw Cather as it was called back then) organized the very first CBTC conference, and the IEEE began to develop standards for this emerging technology.

Download a reprint of Railway Age’s Conference Report:

Today, in the 2020s, CBTC has become the de facto industry standard signalling system for metros worldwide. Last year, the IRSE (Institution of Railway Signal Engineers) published a 500-page textbook on Metro Train Control Systems almost exclusively focused on CBTC.

How far have we come in 40 years? Certainly, the technology for implementing CBTC has changed over the years as the industry has taken advantage of new developments in computing and communications technologies. CBTC systems implemented today look very different to the CBTC systems implemented 40 years ago. However, the performance and functional capabilities of CBTC systems, are largely unchanged—they are still typically constrained to the specific ATP (automatic train protection), ATO (automatic train operation) and ATS (automatic train supervision) functions defined in IEEE 1474.1.

Indeed, it could be argued that CBTC systems today have become more complex, more expensive and more difficult to implement, while providing less functionality.

While CBTC systems are still being implemented on fully automated metros, CBTC is also increasingly being applied on metros that are not fully automated, and therefore cannot take full advantage of all of the CBTC capabilities. In addition, such applications also typically specify some level of secondary train detection and/or protection, which significantly adds to the cost and complexity of the signalling solution.

So, with this background in mind, where is CBTC heading?I would respond to that question from two perspectives: First, by doing the same thing differently, and second, by doing something completely different.

By doing the same thing differently, I mean providing the same performance and functional capabilities but using different methods to achieve the same objectives.

“Doing the same thing differently” is essentially what the industry has been doing for the past 40 years, and I would expect this trend to continue as new computing and communications technologies become available, and as alternative means for train location determination, for example, become available. I would also expect to see changes in system architecture with a focus on minimizing track-based signalling equipment, and with more functionalities being moved either to the train or to a central location.

I would hope that this trend will also include the elimination of secondary systems with CBTC, with all trains, including work trains, being CBTC-equipped. There will come a time, I am sure, when the track circuit, and fixed block signalling, will go the way of the horse-drawn buggy. I predict there will be one transit agency out there that will go down in history as the last transit agency to implement CBTC with a track circuit-based secondary train detection system.

As for “doing something different,” I define that as providing additional functionality that currently is not supported by existing CBTC products. This is, I would suggest, the more interesting question.

CBTC, at least in my mind, was never conceived as just another signalling system, but as an enabling technology that would open the door for metro designers and operators to take advantage of and exploit a system that included a smart train, a smart wayside and a robust train-to-wayside data communications network. An enabling technology that could move more people on less expensive infrastructure. An enabling technology that could break down the silos that exist between the various operating system disciplines such as signalling, traction power, tunnel ventilation, fare collection and rolling stock.

For example, there was a time when BART saw a business case in integrating CBTC with the traction power system to control train movements in a manner that minimized peaks in power demand. There was also a time when London Underground saw operational benefits in integrating CBTC with the fare collection/faregate system, or the train’s load-weigh system, so as to adjust service levels in real time in response to actual passenger demands.

My presentation at that very first Railway Age/Parsons CBTC Conference back in 1995, was entitled “Exploiting Operational Benefits offered by Communications-Based Technology” and included the following statement:

“The continuous, bi-direction train-to-wayside communications, high-resolution train location determination and processing capabilities provided by communications-based technology permits handling of large volumes of data and support of complex decision making in real time, resulting in increased service availability in the eyes of the passenger by responding to actual or predicated passenger demands.”

In my view, CBTC should be considred more than just a signalling or train control system, but as a foundational system for enhancing and improving the service provided to passengers.

In fact, I would like to suggest it is time to re-defined CBTC as “Customer-Based Train Control”!

With this in mind, perhaps we need to think about how we go about writing procurement specifications for future CBTC systems. For example, should the specifications be written by signalling or operations specialists? And should CBTC systems be implemented as a signalling project, or as a multi-disciplined customer service upgrade project?

Where Do Interoperability Standards Fit?

I must confess that personally I am not a big fan of developing national or international interoperability interface standards for CBTC, if the primary objective is to configure a CBTC signalling solution with train-borne and wayside components procured from different CBTC subsystem suppliers. The least-risk, lowest-cost approach, in my opinion, from both an initial capital cost perspective and a life cycle cost perspective, is always to procure a CBTC solution from a single supplier. Procuring a CBTC solution from a single supplier also simplifies systems integration, safety certification, future system upgrades and obsolescence management.

I believe CBTC’s current dominance as the signalling concept of choice for metro systems is that it has not been constrained to a specific computer or communications technology, means of train location determination, system architecture or a grade of automation. It has given the transit agencies and the suppliers the flexibility to do things differently and do different things to meet the unique needs of each metro operator.

A good example of a single-supplier, single-product approach is of course the Vancouver Skytrain system, where the same CBTC solution from the same supplier has been installed on all subsequent new lines and line extensions. While the specific technology has evolved over time, the Vancouver-specific CBTC system architecture and interoperability interfaces have remained unchanged. BART in San Francisco and MTRC in Hong Kong are additional examples of other agencies that have adopted a single-supplier, single-product solution.

I do, however, understand the perceived attraction of interoperability interface standards, from a commercial perspective, and indeed for some large transit agencies, such as New York, there may be a business-case in developing local, agency-specific standards for multi-supplier procurements. However, there are significant costs, risks and constraints that must be acknowledged with this approach. Also, it is highly unlikely, in my opinion, that site-specific standards developed by one transit agency will be transferable to another transit agency.

Parsons’ Lori Colangelo asks: How we can get large networks such as BART and WMATA implemented and not be tied to a single vendor? I know interoperability is an issue, but so is being captive to one vendor for the entire system, and bandwidth to execute by supplier is limited.

Lori’s question implies that being captive to a single vendor, and a single CBTC product, is a problem. I’m not sure that necessarily is the case. Indeed, a muti-supplier, multi-product scenario is likely to be a far more significant problem. If a transit agency is looking to replace an aging fleet of railcars, for example, it would not be unusual for that transit agency to issue a multi billion-dollar contract to a single carbuilder.

So, if a transit agency is looking to replace an aging signalling system— which would cost significantly less than railcar fleet replacement, why would that transit agency be unwilling to entrust the work to a single CBTC suppler? As I noted earlier, I believe a single-supplier, single-product solution will always be the least-risk, lowest-cost way to go.

If the concern is that a single supplier doesn’t have the capability to deliver all the work, then I would suggest the agency needs to look closely at the scope of the supplier’s contract. Is the supplier’s scope limited to the design and supply of a CBTC product that meets the specified performance and functional requirements? Does the supplier’s scope also include multiple additional project delivery and project management tasks that perhaps could be better implemented and managed by others?

Pete Tomlin asks: I don’t think some agencies, suppliers and consultants do a good job on CBTC projects. What words of wisdom to them, as individuals or as a group, would you like people to stop or start doing?

That’s another great question that could trigger a lengthy discussion!

Let me answer by first noting that as an industry, we have been implementing CBTC system now for 40 years. Whereas logically we would expect the implementation of CBTC projects to have become easier over time, based on all the experience obtained, the current reality would appear to suggest the opposite, with CBTC contracts and CBTC project delivery becoming more and more complex.

We appear to have reached a point were the cost and schedule of a CBTC project is no longer technology-driven, i.e., it’s not driven by the costs and delivery of the specific CBTC equipment, but rather by the nature of the contracting strategy, the size of the delivery organization on both the agency and supplier side, the assurance processes that have been mandated, the governance structure in place, and the method of working adopted on the project.

A few suggestions from me:

1. Stop trying to transfer all the delivery risks onto the supplier. Successfully delivering a CBTC project is a joint supplier/agency responsibility, with each party accepting the risks they are best positioned to manage.
2. Stop specifying complex secondary train detection and train protection systems for unequipped trains. Ensure all trains are equipped and keep the CBTC system architecture as simple and reliable as possible.
3. Stop building huge, complex project delivery organizations. Keep the delivery organization as simple as possible, where the lines of communication and decision-making authorities are crystal clear.
4. Stop imposing complex and unnecessary systems engineering and systems assurance processes that are over and above the supplier’s existing internal processes.
5. Stop expanding the size of the Contract Data Requirements List. Limit the CDRLs to essential documents only, and stop rejecting CDRLs based solely on typos and grammatical errors.
6. Stop believing that a procedure can compensate for a lack of competence. Focus on getting the right person, with the right expertise and experience for each job. People deliver successful projects, not procedures.
7. Stop using a confrontational, contract-compliance-focused delivery model, and instead adopt a collaborative, one-team approach.
8. Stop focusing on whom to blame when the project fails. Focus instead on all participants being winners when the project succeeds.