对CBTC未来的思考（NGTC会议）

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

对CBTC未来的思考（NGTC会议）

原文地址：https://www.railwayage.com

作者：Dr. Alan Rumsey

翻译：徐纪康

主要内容：

分享了他对CBTC未来的想法和愿景。

40年来，我们走了多远？当然，随着行业利用了计算和通信技术的新发展，用于实现CBTC的技术在过去几年中已经发生了变化。今天实施的CBTC系统看起来与40年前实施的CBTC系统非常不同。然而，CBTC系统的性能和功能能力在很大程度上是不变的，它们通常仍然受限于IEEE 1474.1中定义的特定ATP（自动列车保护）、ATO（自动列车操作）和ATS（自动列车监控）功能。事实上，可以说，CBTC系统如今已经变得更加复杂、更加昂贵并且更加难以实现，同时提供的功能更少。

CBTC将走向何方？专家想从两个角度回答这个问题：

第一，以不同的方式实现同样的功能。提供相同的性能和功能，但使用不同的方法来实现相同的目标。

“以不同的方式做同样的功能”基本上是该行业在过去40年里一直在做的事情，我预计随着新的计算和通信技术的出现，以及其他列车定位方法的出现，这一趋势将继续下去。我还希望看到系统架构的变化，重点是最大限度地减少轨旁信号设备，并将更多功能转移到列车或中央。我希望这一趋势还包括取消CBTC的次级列车定位系统，所有列车，包括工程车都配备CBTC。我相信，总有一天，轨道电路和固定闭塞信号系统会像马车一样消失。我预测会有一个地铁运营单位，将作为最后一个使用基于轨道电路的次级列车检测系统实施CBTC而载入史册。

第二，做完全不同的功能。

我将其定义为提供现有CBTC产品目前不支持的额外功能。我认为这是一个更有趣的问题。

CBTC，至少在我看来，从来没有被认为仅仅是一种信号系统，而是作为一种增能技术，为地铁设计工程师和运营公司打开了大门，利用和开发一个包括智慧列车，智慧轨旁和强大的车地数据通信的大系统。 一种增能技术，可以在更便宜的基础设施上增能。一种增能技术，可以打破轨道交通各专业之间存在的数据孤岛，如信号，供电，隧道通风井，闸机和车辆。例如，曾经有一段时间，BART看到了将CBTC与牵引供电系统集成的商业案例，以最大限度地减少电力需求峰值的方式控制列车运行。伦敦地铁也曾一度看到将CBTC与售检票系统，或列车的负载称重系统相结合的运营效益，以便根据乘客的实际需求实时调整服务水平。

事实上，现在是时候重新定义CBTC是“基于乘客的控制系统”！

考虑到这一点，也许我们需要考虑如何为未来的CBTC系统编写规范。例如，规范是否应由信号或运营专家共同编写？CBTC系统应该作为一个信号项目实施，还是作为一个多专业联合的乘客服务项目？

全文

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.

10月26日和27日在费城举行了2023年下一代信号控制会议。Alan Rumsey是CBTC方面的知名专家之一，他分享了他对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.

在我们试图预测CBTC的未来之前，我建议我们首先看看移动闭塞的起源和CBTC到目前为止的演变。

（一）回顾CBTC历史

在寻找移动比赛的起源，我们需要回到50年前。 在20世纪70年代，学术界对一种名为个人快速交通（PRT）的未来交通方式非常感兴趣。这种概念包括非常小的全自动车辆，以非常短的追踪间隔运行，在主要是高架轨道网络上提供起点到目的地的出行服务。只需输入你想要的目的地，一辆车就会自动派到你的位置，把你送到目的地。这种交通方式显然需要非常复杂的控制系统，不仅要保持车辆安全间隔，还要管理和优化网络车辆的进路。

具体来说，控制系统需要高度以乘客为中心，将个人安全，可靠，有效地运送到他们的目的地。

实现这些功能的一个概念被称为“同步移动控制原理”，车辆将被分配并控制沿着轨道运行。为了实现这样的系统，需要能够确定车的位置，能够管理网络中所有车辆的运行，以及车辆和轨旁系统的双向通信。换句话说，PRT系统需要一个我们今天所说的CBTC特性的控制系统。

如果我们把时间往前推到1980年代，我们会发现PRT系统从未实施过，至少没有达到最初设想的水平，但一个有点类似的控制系统出现了，并在温哥华的SkyTrain上实施。SkyTrain 是一种中运量运输系统。它是完全自动化的，由短列车组成，以较短的追踪间隔运行。 该控制系统还采用了“移动闭塞”的理念，要求智慧列车能够根据列车自身的精确位置，分配移动权限。轨旁系统管理列车的进路，以及列车和轨旁之间的双向通信。这是CBTC系统的首次实际应用。

我还记得温哥华Skytrain 的一件事，那就是对CBTC系统的要求影响最大的人，不是信号工程师，而是运营专家。我稍后会再谈到这一点。

如果我们现在再回到20世纪90年代，我们发现CBTC不仅被应用于新建地铁，而且被应用于世界各地的既有线中。例如，伦敦、巴黎、弗朗西斯科、纽约和香港都开始对CBTC概念感兴趣，将其作为增加既有线路运能的一种手段。1995年，组织了第一次CBTC会议，IEEE开始为这项新兴技术制定标准。在今天，CBTC已成为全球地铁信号系统的标准。

40年来，我们走了多远？当然，随着行业利用了计算和通信技术的新发展，用于实现CBTC的技术在过去几年中已经发生了变化。今天实施的CBTC系统看起来与40年前实施的CBTC系统非常不同。然而，CBTC系统的性能和功能能力在很大程度上是不变的，它们通常仍然受限于IEEE 1474.1中定义的特定ATP（自动列车保护）、ATO（自动列车操作）和ATS（自动列车监控）功能。

事实上，可以说，CBTC系统如今已经变得更加复杂、更加昂贵并且更加难以实现，同时提供的功能更少。

CBTC应用于非全自动线路，无法充分发挥所有CBTC的功能。所以，CBTC系统在全自动线路上实施比较有优势。此外，部分CBTC的应用通常还规定了次级列车检测保护，这显著地增加了信号系统的成本和复杂性。

因此，考虑到这样的背景，CBTC将走向何方？我想从两个角度回答这个问题：

第一，以不同的方式做同样的功能。

提供相同的性能和功能，但使用不同的方法来实现相同的目标。

“以不同的方式做同样的功能”基本上是该行业在过去40年里一直在做的事情，我预计随着新的计算和通信技术的出现，以及其他列车定位方法的出现，这一趋势将继续下去。我还希望看到系统架构的变化，重点是最大限度地减少轨旁信号设备，并将更多功能转移到列车或中央位置。

我希望这一趋势还包括取消CBTC的次级列车定位系统，所有列车，包括工程车都配备CBTC。我相信，总有一天，轨道电路和固定闭塞信号系统会像马车一样消失。我预测会有一个地铁运营单位，将作为最后一个使用基于轨道电路的次级列车检测系统实施CBTC而载入史册。

第二，做完全不同的功能。

我将其定义为提供现有CBTC产品目前不支持的额外功能。我认为这是一个更有趣的问题。

CBTC，至少在我看来，从来没有被认为仅仅是一种信号系统，而是作为一种增能技术，为地铁设计工程师和运营公司打开了大门，利用和开发一个包括智慧列车，智慧轨旁和强大的车地数据通信的大系统。 一种增能技术，可以在更便宜的基础设施上增能。一种增能技术，可以打破轨道交通各专业之间存在的数据孤岛，如信号，供电，隧道通风井，闸机和车辆。

例如，曾经有一段时间，BART看到了将CBTC与牵引供电系统集成的商业案例，以最大限度地减少电力需求峰值的方式控制列车运行。伦敦地铁也曾一度看到将CBTC与售检票系统，或列车的负载称重系统相结合的运营效益，以便根据乘客的实际需求实时调整服务水平。

       早在1995年，我在第一次CBTC会议上的演讲题为“利用基于通信的技术提供的运营优势”，包括以下声明：

1、基于连续、双向通信的技术、高精度列车位置和处理能力，允许处理大量数据并支持真实的复杂决策，从而通过实时响应和预测乘客的需求，来提高服务水平。

2、在我看来，CBTC不应仅仅被视为一个信号或列车控制系统，而应被视为一个增强和改善服务水平的基础系统。

事实上，我想建议现在是时候重新定义CBTC是“基于乘客的列车控制系统”！

考虑到这一点，也许我们需要考虑如何为未来的CBTC系统编写规范。例如，规范是否应由信号或运营专家共同编写？ CBTC系统应该作为一个信号项目实施，还是作为一个多专业联合的客户服务项目？

（二）互联互通标准适用于何处？

我必须承认，如果主要目标是使用从不同CBTC子系统供应商采购的车载和轨旁组件配置CBTC信号解决方案，那么互联互通是合适的。

我个人并不热衷于为CBTC制定国家或国际互操作性接口标准。在我看来，从初始资本成本和生命周期成本的角度来看，风险最小、成本最低的方法始终是从单一供应商处采购CBTC解决方案。从单一供应商采购CBTC解决方案还可以简化系统集成、安全认证、未来系统升级和淘汰管理。

       我认为，CBTC作为地铁系统首选信号系统是因为，它并不局限于特定的计算机或通信技术、列车定位手段、系统架构或自动运行等级。它为运营公司和供应商提供了灵活性，可以采用不同的方法实现相同的功能，以及针对业主定制不同的功能，以满足每个地铁运营商的独特需求。

       温哥华SkyTrain系统就是单一供应商、单一产品方法的一个很好的例子，在该系统中，来自同一供应商的相同CBTC解决方案已安装在所有后续的新线路和线路扩展上。虽然特定技术随着时间的推移而发展，但CBTC系统架构和接口保持不变。

       然而，我理解从商业角度来看互联互通接口标准的明显吸引力，实际上，对于纽约地铁等一些大型运营单位来说，为多供应商采购制定地方性、机构特定的标准可能是一个商业案例。然而，必须承认，这种做法存在重大成本、风险和制约因素。此外，我认为，一个运营单位制定的针对具体线路的互联互通标准极不可能转用于其他地方的运营单位。

       Lori Colangelo 问道：我们如何才能实现像BART和WMATA这样的大型网络，而不依赖于单一的供应商？我知道互联互通是一个问题，但整个系统被一个供应商俘虏也是一个问题，供应商执行的能力范围是有限的。

Lori的问题意味着，受制于单一供应商和单一CBTC产品是一个问题。我不确定是不是这样。事实上，多供应商、多产品的情况可能是一个更重要的问题。例如，如果一个运营单位正在寻找更换老化的列车，那么该运营单位向一个车辆制造商发出数十亿美元的合同并不罕见。

       因此，如果一个运营单位正在寻找更换老化的信号系统-这将大大低于铁路车队更换成本，为什么该运营单位不愿意委托给一个单一的CBTC供应商的工作？正如我前面提到的，我相信单一供应商、单一产品的解决方案永远是风险最小、成本最低的方式。

       如果担心的是，一个单一的供应商没有能力提供所有的工作，那么我建议该机构需要密切关注供应商的合同范围。供应商的范围是否仅限于设计和供应符合规定性能和功能要求的CBTC产品？供应商的范围是否还包括多个额外的项目交付和项目管理任务，这些任务或许可以由其他人更好地实施和管理？

       我不认为一些机构、供应商和顾问在CBTC项目上做得很好。作为个人或团体，你希望人们停止或开始做什么？

       这是另一个可能引发长时间讨论的好问题！

首先，作为一个行业，我们已经实施CBTC系统40年了。虽然从逻辑上讲，我们会期望CBTC项目的实施随着时间的推移变得越来越容易，但根据所获得的所有经验，目前的现实似乎表明相反，CBTC合同和CBTC项目交付变得越来越复杂。

       我们似乎已经达到了一个点，即CBTC项目的成本和时间表不再是技术驱动的，它不是由特定CBTC设备的成本和交付驱动的，而是由合同策略的性质，机构和供应商方面的交付组织的规模，已授权的保证流程，到位的治理结构以及项目采用的工作方法驱动的。

（三）建议：

1、不要试图将所有的风险转移到供应商身上。成功交付CBTC项目是供应商/业主的共同责任，各方都要接受他们最有能力管理的风险。

2、停止为列车配置复杂的次级列车定位检测系统。确保所有列车都配备了CBTC系统，并保持CBTC系统架构尽可能简单和可靠。

3、停止建立庞大、复杂的项目交付组织。保持交付组织尽可能简单，其中沟通和决策当局的线路非常清晰。

4、停止强加复杂和不必要的系统工程和系统保证流程，这些流程超出了供应商现有的内部流程。

5、停止扩大合同数据要求列表的大小。将CDRL仅限于基本文档，并停止仅基于拼写错误和语法错误拒绝CDRL。

6、不要相信一个程序可以弥补能力的缺乏。专注于找到合适的人，每个工作都有合适的专业知识和经验。交付成功的项目，而不是程序。

7、停止使用对抗性的、以合同合规为中心的交付模式，而是采用协作性的、一个团队的方法。

8、当项目失败时，不要再关注谁该受到责备。相反，当项目成功时，所有参与者都是赢家。

原文如下：

（一）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.Today, in the 2020s, CBTC has become the de facto industry standard signalling system for metros worldwide.

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:

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.

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.

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.

Stop imposing complex and unnecessary systems engineering and systems assurance processes that are over and above the supplier’s existing internal processes.

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.

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.

Stop using a confrontational, contract-compliance-focused delivery model, and instead adopt a collaborative, one-team approach.

Stop focusing on whom to blame when the project fails. Focus instead on all participants being winners when the project succeeds.