Positive Train Control
Positive Train Control (PTC), a means to prevent accidents due to train crew errors, has been a priority of the National Transportation Safety Board since the 1970s. The recent Chatsworth accident, where a train engineer missed a red signal because he was texting on his cell phone, moved the federal government to mandate the installation of PTC on all passenger railroads and freight main lines by December 31st, 2015.
Positive Train Control is achieved by hardware and software that continually monitors and enforces the train crew's compliance with movement authority (the permission to occupy a portion of track for a certain distance, time, or speed), and intervenes in case of human error. PTC consists of three major functions:
- preventing train-to-train collisions
- preventing trains from exceeding speed limits
- protecting work zones with personnel near or on the tracks
The Federal Railroad Administration has issued a Notice of Proposed Rule Making detailing the regulatory requirements with which all PTC systems must comply. Besides describing the history and context of the new rules, the NPRM specifically states that "wherever possible, FRA has attempted to refrain as much as possible from developing technical or design standards, or even requiring implementation of particular PTC technologies that may prevent technological innovation or the development of alternative means to achieve the statutorily defined PTC functions." Appropriately, PTC is being defined as a function, not a product.
Efforts to implement PTC products have been afoot for years. The freight railroads are now chafing at the scope and cost of the unfunded PTC mandate, calling into question whether it can be met by 2015. Five years is a short time to standardize a technology and to deploy it on a grand scale--over 30,000 locomotives and 100,000 miles of track for just the five largest freight railroads.
The Universe Beyond PTC
As narrowly defined by the FRA, Positive Train Control by itself does not suffice to run a high-speed passenger railroad. Achieving a safe flow of rail traffic requires myriad systems that generate and communicate movement authorities to each train, perform track clear detection (when a portion of track is free to be entered by a train), dispatch and optimize traffic flows, monitor system status and health, and even drive the trains in the smoothest and most energy-efficient way. These systems are known by an alphabet soup of acronyms that are often specific to signalling practice, railroad culture, or specific products in various countries. Those who wish to dig deeper might read the book Railway Operation and Control by Joern Pachl, for an accessible and culturally comprehensive overview of quite a complex subject.
Today, Caltrain uses a widespread technology known as Centralized Traffic Control (CTC). A dispatching office in San Jose operates the peninsula corridor by remote control, through relay-based logic that safely sets all switches and signals. The train crew is responsible for observing signals and speed limits, and may communicate with the dispatcher by voice radio. This system is ill-suited to running high traffic densities at high speeds; therefore, an improved signal system is considered a top priority in the Caltrain 2025 plan (now being merged into the Peninsula Rail Program). That system is known internally as CBOSS.
Caltrain's CBOSS
CBOSS, or Communications-Based Overlay Signal System, implements PTC functions and many additional features. Its key benefits are stated to be:
- increased safety, implementing all three functions of PTC
- increased capacity of the peninsula corridor, as measured in trains per hour
- enforcement of traffic separation between freight and passenger trains, to support Caltrain's transition to lightweight EMUs
- reduction of crossing gate down-times
Like many modern train control systems, CBOSS consists of train-borne equipment, wayside and track equipment, a dedicated radio communication network, and an interface to the dispatching center. There are plans to reuse as much hardware and software as possible from the emerging PTC systems being developed by and for the freight railroads.
CBOSS Meets HSR
In November 2008, after CBOSS specifications were well underway, high-speed rail suddenly became a realistic prospect rather than a distant fantasy. Sharing the peninsula corridor with HSR has enormous implications for CBOSS. Consider the changes:
- The peninsula corridor will become a small portion of the future statewide HSR system.
- To operate at 220 mph in all weather conditions (e.g. Tule fog), high-speed trains will be fitted with train control systems that may be different, more sophisticated or more capable than CBOSS.
- Grade crossings, a major focus area for CBOSS, will largely disappear from the peninsula.
- All track circuits, signals, interlockings, etc. will be reconfigured or replaced when tracks are added or modified.
- The high speed rail project has far deeper pockets than Caltrain, so retaining existing infrastructure is less pressing a concern because economies of scale can be realized statewide.
Train Control Systems Are Hard
Developing, integrating, testing and deploying safety-critical software and hardware is no picnic. It is neither easy, quick, nor cheap, especially when the technology is new. The recent history of train control system development, even here in the Bay Area, is littered with projects that were delivered years late, millions over budget, or even not at all. Without fail, new train control systems follow the development profile shown in the cartoon at right.
- BART developed a new signalling system known as AATC (Advanced Automatic Train Control) starting in 1998. Difficulties with integrating the software with the hardware eventually forced BART to scrap AATC in 2006 after $80 million had already been spent.
- MUNI's Advanced Train Control System, intended to improve capacity of the MUNI Metro, was late, over budget, and did not perform as intended. It caused the spectacular MUNI Meltdown in 1998, and still struggles to achieve its performance objectives.
- Amtrak developed an overlay PTC system for the Northeast Corridor known as ACSES, to supplement the legacy cab signal system. Derived from a French technology, it entered testing in 1996 and did not achieve reliable data radio operation until 2005.
- ERTMS, the European Railway Traffic Management System, is probably the most ambitious system development in the last decade. ERTMS attempts to unify technology and operating practices across Europe. Its development was dogged by requirements instability, and its high cost made for a questionable business case where existing train control systems already functioned adequately. A software error even caused a minor accident in 2007. Deployment is years behind schedule and massively over budget, with major fiascos in the UK and the Netherlands.
One can reasonably infer that it is exceedingly unlikely that Caltrain, but a small speck in the universe of passenger rail, can single-handedly develop something as technically complex and refined as CBOSS within any reasonable schedule or budget--much less if it hitches its wagon to freight PTC. The HSR project raises the stakes even higher than the FRA PTC deadline, because CBOSS must first work reliably to enable the construction of HSR infrastructure while maintaining Caltrain operations. A failure would be compounded--imagine Caltrain's CBOSS program delays cascading to the statewide HSR system, resulting in idle tracks with no trains. Despite the best intentions and deep expertise of the development team, the chances of a fiasco are alarmingly high.
Of course, this nightmare scenario is not a foregone conclusion, although one would hope that the mere prospect would be considered one of the highest risks to the Peninsula Rail Program, whether on technical performance, cost, or schedule.
CBOSS compared to ERTMS
The CBOSS project has ambitions that reach beyond Caltrain. A report states that "Caltrain has noted with some focus that if desired or required, CBOSS is capable of being readily extended, not only to adjacent properties, but broadly within the industry to ensure solid and sustained support within the industry." There's even hopeful talk of CBOSS being considered for HSR. Since CBOSS wants to play in the big leagues, it’s only appropriate to compare it to the current state of the art, namely ERTMS (the European Railway Traffic Management System, often referred to by its component system ETCS, the European Train Control System). Why ERTMS, despite the development failures cited above?
In short, that was then, this is now.
ERTMS is now over the development "hump" and is gradually maturing to the point of becoming a worldwide standard in passenger rail applications. Despite its European origins, it is now being deployed in many countries outside of Europe; it's hard not to notice Australia, China, India, Saudi Arabia, South Korea or Taiwan jumping on the ERTMS bandwagon.
The following comparison points out key differences between CBOSS and ERTMS:
Who controls the specification | |
CBOSS: Caltrain | ERTMS: UNISIG, a consortium of suppliers, and the ERTMS Users Group in Brussels, composed of European rail administrations. |
Is it a standard? | |
CBOSS: No, although it’s envisioned to spread beyond Caltrain. | ERTMS: Yes. Does not belong to any operator or vendor. Once agreed upon, the standard is administered by the European Railway Agency. |
Requirements maturity | |
CBOSS: Low to moderate. All reviews are performed by stakeholders (Caltrain, consultants, FRA, vendors) who have an interest in CBOSS going ahead as planned. No independent requirements validation performed other than expert consensus on the specification. Heavy reliance on expertise of developers. | ERTMS: Moderate to high, after a long period of requirements instability. Requirements honed by many organizations that set aside their respective technological and cultural traditions. Initial deployments are complete, requirements are stabilizing, and validation experience is being fed back into the ETCS 3.0.0 System Requirements Specification due out in 2012, the culmination of nearly two decades of development. |
Development risk | |
CBOSS: Development “hump” looms ahead. Risk managed by "debate" instead of formal systems engineering risk management methods. Caltrain / Peninsula Rail Program implicitly take on all technical, schedule and budget risks, with CBOSS and PTC squarely in the critical path of the Peninsula Rail Program. | ERTMS: Already developed and de-bugged using a lot of other people’s sweat, pain, and money. ERTMS is over the development "hump" and the majority of risks have now been retired. The proof is in the pudding: for example, Mattstetten - Rothrist in Switzerland is operating at 242 trains/day with headways of 110 seconds and speeds of 200 km/h. |
Development expense | |
CBOSS: High. In its first phase, this is undeniably a research and development project. The rigorous testing and certification of safety-critical software and hardware is not cheap, especially when requirements instability causes several rounds of change orders and regression testing. | ERTMS: Low, provided the standard is complied with. Development is complete and the system is already in wide operation. Non-recurring expenses would arise primarily from bringing ERTMS to the U.S. for the first time. |
Deployment expense and economies of scale | |
CBOSS: Recurring cost expected to be low, due to reuse of hardware and software designed for freight PTC (e.g. low-cost wayside interface units). Leverages the economies of scale from a PTC installed base that is planned to rapidly surpass ERTMS. | ERTMS: Perceived to be high, because of the complexity of the system. While multiple vendors exist, they operate as a consortium (UNISIG) that may function as a de-facto cartel. Some economies of scale realized across many international installations, although they may not be passed on to customers. |
Radio communications infrastructure | |
CBOSS: Undetermined, although IEEE 802.11n (Wi-Fi) or 802.16e (WiMAX) is possible. | ERTMS: Dedicated GSM-R digital cellular voice & data. GSM is an aging "2G" standard that will soon be obsolete, and the wayside infrastructure is expensive to install. Radio spectrum does not currently exist, and would need to be allocated by the FCC outside of commercial GSM cell networks. |
Support for highway grade crossings | |
CBOSS: Enables “smart” crossing gates that stay open when a train makes a station stop just short of the crossing. Enables real-time health monitoring of crossing warning devices, with automatic train speed restriction in case of failure. These capabilities will be developed despite the high probability that Caltrain will be largely grade-separated for HSR. | ERTMS: Does not integrate with grade crossing warning devices, which remain a separate system. |
Support for high speed rail | |
CBOSS: Claimed to be fully compatible, to the extent that developers have experience with foreign HSR systems. There has been no explicit engineering coordination between CBOSS developers and the CHSRA and its consultants (besides a few consultants moving from CBOSS to the HSR project), and California HSR requirements and design criteria are undetermined. | ERTMS: The new standard for high-speed rail in Europe, used on nearly every high-speed line opened to service in the last five years. |
Interoperability | |
CBOSS: Based on freight PTC technology, so freight PTC equipment (UPRR and Amtrak) can operate seamlessly on the peninsula. | ERTMS: Would require installation of train-borne equipment in addition to PTC, for any UPRR or Amtrak trains operated on the peninsula (e.g. using a surplus Caltrain diesel on the front of the train). On the other hand, if the ERTMS standard were selected for California HSR, compatibility with HSR would be built-in from the start. |
System of units | |
CBOSS: United States customary units. | ERTMS: Metric system, requiring conversion of all legacy documentation, databases, and equipment. |
Flexibility | |
CBOSS: Allows the definition of up to 64,000 train performance profiles. | ERTMS: Allows only 18 (?) different train performance profiles. (section 3.13.2.2 of the ETCS specification) |
Risk of vendor captivity | |
CBOSS: High. Despite its ambitious vision, Caltrain remains a tiny operation with less than 50 route miles and $100M yearly operating budget. The entire CBOSS contract will be awarded to one winning bidder, and Caltrain would have no back-up if the vendor lost interest in the product. (This happened recently with Caltrain's dispatching software, instantly made obsolete when the vendor walked away from the product.) | ERTMS: Low. Multiple vendors including some of the biggest names in the business, although without a large U.S. presence due to the protectionist stance of the industry. Wide range of off-the-shelf products, in conformance to mature and widely-used standards specifications. Growing installation base guaranteed by European mandate. |
Country of origin | |
CBOSS: Made in the U.S. of A. using All-American stimulus dollars. | ERTMS: Not Invented Here. Has letter ‘E’ in acronym. |
The Case Against ERTMS
Most arguments against the suitability of ERTMS for the peninsula corridor, advanced by a key CBOSS developer, fall into three broad categories.
- The Exception Hypothesis: Caltrain is different, unique, and special. Mixed train performance, grade crossings, etc. require a special system that mitigates operating hazards that are unique to Caltrain. The new train control system must accommodate all operating rules. Outside people just can't understand the unique operating needs and environment of Caltrain.
- Blind Faith in U.S. Freight PTC: Caltrain must use a system that is interoperable with freight trains, especially on the Gilroy branch. Freight PTC is a mature technology that will become a standard and be deployed nationwide by 2015. Freight PTC is the ideal base for Caltrain's needs, and reuse of freight PTC components will guarantee low costs. Caltrain must use a radio system that operates within legacy railroad frequencies.
- Not-Invented-Here Syndrome: U.S. railroad folks are a conservative bunch, and ERTMS would be too much change to swallow at once. ERTMS does not meet Caltrain's operating needs or U.S. operating practices. ERTMS isn't PTC. ERTMS still doesn't work. ERTMS contains latent software bugs that will degrade safety and might cause a fatal accident. ERTMS is not interoperable with U.S. freight trains. ERTMS is metric. (yuck!) ERTMS is controlled by European bureaucrats and the U.S. had no input to the specification. ERTMS can't be used as-is and must be modified at great expense--and bastardizing ERTMS is worse than developing something new and better.
The Case For ERTMS
Suppose that Caltrain's primary business is to carry passengers, and not to undertake major new technology development projects with a price tag more than twice annual revenue.
Suppose that a CBOSS development failure is actually not an option, since it would snarl the entire Peninsula Rail Program.
Suppose that there are many program risks that threaten the smooth execution of the Peninsula Rail Program, and that CBOSS development risk borrows more trouble than it's worth when demonstrated solutions exist.
Suppose that using a train control system shared by Caltrain and HSR is actually desirable, for a rail corridor shared by Caltrain and HSR (minority freight traffic notwithstanding).
Suppose that Caltrain developing a new train control technology for HSR amounts (at best) to the tail wagging the dog, or (at worst) to the future need for redundant on-board equipment on every single high-speed train in California.
Suppose that operating rules can be tailored to the technology, rather than demanding that the technology conform totally and completely to operating rules and "elicited needs." (with the added opportunity of invoking paragraph 8.3.(c)... hint hint)
Suppose that being locked into a single vendor does not promote vigorous competition and healthy long-term viability of your supplier base.
Suppose that freight PTC might not become all that it's cracked up to be, especially not by the 2015 deadline of the government's unfunded mandate, forcing Caltrain to continue operating obsolete, unreliable diesel trains long past their expiration date.
Suppose that Caltrain is capable of the same zeal and pragmatism in pursuing FCC spectrum for GSM-R (or any other minor regulatory obstacle) as they display when running the red tape to import off-the-shelf European EMU trains that are "non-compliant" with FRA regulations.
If these suppositions sound remotely reasonable, then the Peninsula Rail Program should take the bold and visionary step of adopting ERTMS--warts and all. ERTMS would mitigate development risk, guarantee future compatibility with HSR, and avoid dependency on a single vendor.
If these suppositions are false, then maybe it's time to invent a better mouse trap than ERTMS. Best of luck with that.