The passage of California Proposition 1A (2008) set in motion a complete reconstruction of the railroad between San Jose and San Francisco. This blog exists to discuss compatibility between HSR and Caltrain, integration issues, and the impact on adjoining communities.

28 October 2009

Peninsula Train Control: PTC, CBOSS and ERTMS

Trains on the peninsula today rely on light signals placed next to the tracks that indicate whether it is safe to proceed. In order to safely operate a train, the crew must view and interpret these signals, a process that is inherently vulnerable to human error. While error-prevention protocols are in place to minimize the likelihood of such errors, they can still happen, with deadly consequences.

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

PTC is not just hardware and software; it is a function. PTC is not new; there are many existing train control systems in operation around the world that implement some or all functions of PTC. PTC is not foreign; it already exists on several passenger railroads in the United States (most notably on Amtrak's Northeast Corridor) and is common in urban rail systems such as BART.

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

CBOSS is an overlay system, in that it makes few changes to the underlying vital infrastructure that controls trains on the peninsula, namely the signals, interlockings and Centralized Traffic Control used to generate and communicate movement authorities, and the track circuits used for track clear detection and grade crossing protection. One of the key design drivers for CBOSS was to avoid altering or replacing this infrastructure, gradually built up in the last fifteen years within Caltrain's limited budget.

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.

HSR brings one undeniable advantage: financial resources that dwarf anything that Caltrain could muster by itself. Thanks to HSR, CBOSS figures prominently in the short-term funding strategy for the peninsula corridor, with $230 million requested in the MTC's Peninsula Corridor Investment Strategy. The contract to build CBOSS is due out to tender in November 2009.

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.

These examples illustrate the enormous--and systematically under-appreciated--risk that is inherent in developing and deploying sophisticated new safety-critical embedded systems.

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.

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. Used at 500+ km/h during 2007 rail world speed record. Worldwide standard for green-field HSR installations (China, Argentina, etc.)

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.

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.

Most of these arguments boil down to pounding the pulpit. News flash: Caltrain is an insignificant, two-track back-and-forth operation with sparse traffic, no complex junctions, and a tiny fleet. It will remain so for the foreseeable future.

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.

just because it is possible to implement multiple signaling systems in train cabs (Eurostar has 4) doesn't mean it's something the US should strive for.

ERTMS has indeed had a difficult gestation period, partly because of the technical difficulties in getting GSM-R to work reliably but mostly because bureaucrats and vendors in each country were desperately trying to defend their fiefdoms.

If ERTMS is to be adopted as a national standard in the US, several things need to happen IMHO:

(a) the name needs to change to something like Global Rail Traffic Management System (GRTMS). That woudl take the jingoistic emotion out of what needs to be a 100% rational safety engineering task.

(b) FRA needs a seat at the rule-making table, at least for the aspects that really are unique to North America, e.g. the fact that US freight trains are much longer and much heavier than those in Europe. That creates an opening for US vendors to enter the PTC market without having to resort to protectionism.

(c) Congress needs to put some money on the table to persuade both Amtrak and US freight rail operators to adopt this global standard rather than waste time and money developing a proprietary solution.

Caltrain will get that money via the HSR project, which will entail full grade separation of the entire ROW between at least SF and SJ Diridon. The changes in the vertical profile of the alignment anyhow mean most of the existing signaling equipment has to be torn down in any event. The only question is if it should be re-used, sold off or scrapped.

(d) FCC needs to approve a frequency band for GSM-R.

In parallel, the GRTMS standards body needs to develop a next-gen radio communications standard that is a better fit for the vast empty spaces in the American West and indeed, many other places in the world.

Uplinks to geostationary satellites and terrestrial WiMAX (802.16e) base stations on mountaintops, at the top of tall masts or attached to tethered balloons could all be worth considering. Each has cost vs. reliability vs. environmental trade-offs.

"This is actually very common in Europe - most trains that operate on both HSR and "regular" tracks or that operate internationally have ob-board equipment for multiple train control systems."

Over 20% of the price of contemporary European universal (multi-voltage, multi-signal) locomotives can be attributed to the cost of the multiple signal systems AND THE INTERFACES BETWEEN THEM.

(FYI multi-voltage is almost free, in fact nowadays if one buys what appears to be a 15kV-only medium-power loco to haul around one's commuter trains one is really buying a common platform locomotive with some stuff not connected or configured.

This is NOT SO for the ETCS/LZB/TVM/TPWS/KVB/RS4/PZB/LS90/AWS/TBL/SCMT/ATC/ATB/RVM/ZUB/etc nightmare. There's a reason why entire countries want to go with one, universal, DEBUGGED, proven system and not borrow the pain and known agonies of unending multi-system horror.)

Iit's very easy to see why power-mad or merely-hubristic second-stringers on the global rail scene or cash-hungry small-pond consultants might have a perfectly rational interests in the prospect of permanent employment and infinte cost escalation ... but for those of you who have an interest in seeing running trains carrying passengers ...

The frequency band issue shouldn't be too big of a deal. The 700mhz D-block didn't sell last year, and AFAIK is still available. It's within the worldwide GSM frequency range, and is actually a longer wavelength than GSM-R was given, so that should help with things like interference and coverage area. Really though the radio technology isn't as difficult to change as the other pieces, it's conceivable that they could run it on another technology altogether, though it seems like a good idea right now to grab some of that D-Block while it's available.

However, as with Caltrain, the change affects only drivers and other on-board staff. It does not mean Amtrak will be responsible for the capital improvements projects required to implement PTC in SoCal by the 2015 deadline.

Settling on ERTMS with GSM-R on the 700MHz D-Block for all of California would be a huge step forward. Does CPUC have any jurisdiction over PTC implementations in the state?

It doesn't matter if some specific GSM-R frequencies are available or not.

It wouldn't matter if Siemens Transportation Systems came in and supplied a complete Caltrain-wide GSM-R radio system at no cost.

It wouldn't matter if Alcatel came in and provided a full corridor-wide ETCS Level 2 signal system for free and then on top of that gave a sold gold souvenir Eurobalise to everybody in Caltrain's world class engineering department.

None of that would matter.

Because.

Because that's never going to be good enough.

Because We're Special.

Extremely Special.

And we're Differently Abled. Very Differently Abled indeed.

And you just don't understand Just How Special We Are.

You can't. Because there are just some things you'll never be able to get.

Because you're not a Special All-American Railroading Dude. And nobody else is either sensitive enough or tough enough to understand just how special our needs are.

But we'll show you.

Just you wait and see.

In the mean time, please deliver a couple hundred million in small unmarked bills. It's the least you could do for somebody with such Special Needs.

Is GSM hardwired into ERTMS? Or could the US adopt an ERTMS implementation that uses CDMA communications? It's not that the US shouldn't switch to GSM in general, but that if it doesn't, it may be cheaper to tweak ERTMS to work with CDMA instead of replace CDMA.

Thanks Marcel for the correction. Come to think of it, I wonder if TVM was even used for the test... there was no need to assure any sort of train separation during those test runs, since the train had the track all to itself.

Rafael, I had forgotten everything about the tethered balloons. Sorry about that.

Alon, the issue is that the train control system must use a dedicated band away from commercial cell bands to assure that a channel is always available. It's not a GSM vs. CDMA thing. The band issue is probably similar for WiFi or WiMAX: you need a dedicated frequency that is guaranteed never to be oversubscribed.

If we end up with a signaling system on the peninsula denominated by furlongs and miles and slugs and gallons......

Seriously, even if CHSRA and/or Caltrain have problems with using ERTMS/ETCS for spectrum reasons or whatnot, can we just get SNCF to install KVB? It works for the speeds on the peninsula, and it has a proven track record!Why not make people's lives easier and spend less money?

If Caltrain makes its new system in customary units, there should be some criminal consequences for Caltrain management for money laundering and fraud.Seriously

Trains aren't built in customary units. Signaling systems don't work with customary units. 95% of the world doesn't know what a mile is.SI units have been around for a few centuries. Caltrain doesn't need to waste money staying in the 18th century

Settling on ERTMS with GSM-R on the 700MHz D-Block for all of California would be a huge step forward. Does CPUC have any jurisdiction over PTC....FCC needs to approve a frequency band for GSM-R

There is life east of the Sierra Nevada. There's life beyond the borders of the the US. The ITU decides what can be done in each region. Anyway locomotives and whole trains frequently travel outside of the US into Canada and Mexico. Might be handy if everyone in ITU region 2 decided to do the same thing.

Uplinks to geostationary satellites

Go out of view in valleys, behind tall trees, steel buildings... They'd have to use something like Iridium and they'd still have dead spots.

and terrestrial WiMAX (802.16e) base stations on mountaintops, at the top of tall masts or attached to tethered balloons could all be worth considering. Each has cost vs. reliability vs. environmental trade-offs.

They aren't going to be using equipment any hacker can buy in Radio Shack with cash. Or gets overwhelmed when the rancher decides to juice up his WiFi base station so he can surf the web when he's at the other end of the pastures.

The base stations need to be connected to the control center somehow. . . fiber optic line along the ROW? If they are laying cable to connect a remote base station on a mountain top it's probably cheaper to install typical base stations on cheap structures along the ROW every few miles before they can justify roads up mountainsides or tall masts. Keep in mind that railroads tend to be down in the valley where there are mountains. The mountain top or balloon goes out of view once you get to the next mountain. Even relatively long distance fiber links need repeater stations every so often. They could put the base stations where the repeaters are...

It's not that the US shouldn't switch to GSM in general

If you want a GSM phone in the US they are available. Biggest carrier that uses GSM is ATT. As Andy pointed out the railroads are going to have a network that is separate from the public one. First generation GSM phones used TDMA. 3G phones will use CDMA.

Trains aren't built in customary units.

Neither are cars, haven't been for decades. They still go 75 MPH though. There was a brief period if they were going around 60 miles per hour they were also going 100 kilometers per hour. And all the systems in the car that made it go that fast and then stop when the driver decided to stop for the stop sign at the bottom of exit ramp didn't depend on whether or not the speed was expressed in MPH or KPH.

Signaling systems don't work with customary units.

They don't work in SI units either. There's a long complex process that eventually results in some number being displayed in a cab. The number being displayed in the cab is up to the designer of the display. No reason why it couldn't display both or display the speed in MPH, KPH and cubits per hour along with the wind speed at the airport in Eureka and the price of broccoli at Safeway versus Kroeger. The engineer of the train doesn't care if that number is MPH, KPH, or cubit per hour, all he needs to do is match his speed to that number.

If you want to rant about it, then you should know that Imperial units were standardized in the 19th century, a few decades after France developed the metric system.

... and are defined as fractions of their complementary SI units. A pound is 453.59237 grams and a mile is 1,609.344 meters.. or something like that.

"Might be handy if everyone in ITU region 2 decided to do the same thing."

Agreed. It would be ideal if all NAFTA countries decided to adopt a single standard for PTC implementations.

The question is how to get to that happy state of affairs. In the past, it's often been the case that California is out ahead of the nation on new standards and other states and/or the federal government then follow.

California is the only state actively working on a full-fat HSR system right now. For sound reasons, it wants to use off-the-shelf technology that others have already debugged.

That said, what are the relative merits of ACSES vs. ETCS level 2? After all, ACSES is already installed in the NEC and afaik also very reliable. It's just that's it's a proprietary system rather than a standard that multiple vendors are implementing.

Is ERTMS even architected such that the lowest level (automatic train control) can be cleanly swapped out, cp. hardware abstraction layer in computer operating systems?

Rafael, the main difference is that ACSES is not a complete train control system. It is only an overlay, which adds PTC functionality to a pre-existing coded track circuit cab signal system that is today obsolete. You would never chose that for a fresh installation.

If you think large construction projects tend to go over budget, they have nothing on large IT projects.

The outright Failure Rate for large IT projects is somewhere around 30%. ("large" generally being defined as over $1m). Those that don't outright fail tend to go over budget by about 100-200%. The on-time, on-budget record for your average large IT project is something like 10-20%.

Software and hardware development make building a new Bay Bridge look like a cakewalk.

To embark on a new effort to build a full system like this when MULTIPLE other systems already exist is, and I feel like Richard here, a criminal waste of funds.

The risk mitigation ALONE of purchasing an off-the-self system is worth any additional integration or purchase costs of an already-built system – to say nothing of the future costs associated with modifying any "off the shelf" HSR trainsets that the authority wants to buy.

Sorry about how my old comment was a bit rhetorical...My overall point was that there is a thriving international market in trainsets and signaling systems, and it would be ridiculous to lock the Peninsula out of that market.And while there certainly isn't any inherent advantage to using metres-kilograms-litres over miles-pounds-gallons, using the SI/metric units means that we wouldn't pay to retrofit trains from a market universally denominated in SI units. Even if the tachometers of the train can't tell the difference

WRT ETCS, I think it would be easier to buy a standard system and paying to retrofit UP's locomotives with the GSM radios and balise transponders.And ETCS seems to be the future direction for the industry. As pointed out originally, projects use ETCS for new installations, and using the Northeast Corridor's/other existing systems would require using legacy technology (since the PRR and its pulse signals aren't around anymore)

Obviously trains will need to be designed for Unique Californian Conditions.

And some consultant -- like the rent-seeking sleazebags at LTK Engineering Services who colluded in a "study" concluding that SMART in Marin-Sonoma must run high-floor, decades-obsolete, FRA-crippled, craptastic, USA-built, USA-designed, fuel-inefficient, trade-protected, over-weight over-cost jalopies and then just happened to be awarded a contract to specify the design of those craptastic USA-USA-LTK-FRA-DMUs -- will need to write the Unique California Specifications for the one-off Caltrain Cars. And that's just warm-up for one-off California Acelas. Mmmmmmm.....

And some consultant will have to design the Test Track. And somebody will have to build the test track. And the Signal Test Facility. And somebody will have to manage the Testing Program. The Testing Programs, that is. And somebody will have to issue the Engineering Change Orders for the failing vehicle dynamics. And somebody will have to issue the Engineering Change Orders for the failing CBOSS system interface. And somebody will have to manage the above processes. And the interactions between the different failing, ECO-ridden shitstorms. And this will all take many years because, well, you know, these things happen when you're Breaking New Ground on Something That's Never Been Done Before.

"Off the shelf?" Let's face it: who, honestly, is planning that?

Care to imagine what "off the shelf" EMU is going to be seen running Caltain, given that our World Class Caltrain engineering department is inventing its own platform height standards, its own signalling system, its own operating rules, and makes it a matter of religious edict that the trains must be double decked despite Caltrain's trivial level of ridership? Which existing design will that be, then? Oh, and it's using AREMA freight track standards, -- all measured in God fearing feet and inches --, and everybody knows wheel/rail dynamics just a cakewalk with a brand new train design running on third-world-level track. So, 6 months at least of consultant-larded "testing" running the Caltrain Specific California Special Conditions Double Deck EMU round and round in circles at the AAR test track in Pueblo, then, to qualify this new and very special design for our Unique Caltrain Conditions, rather than, say, buying a working train off somebody's production line complete with a working PTC system pre-installed.

The freight RR will, with some justification, say that it wants to be able to allocate any of its (or its leased, or its borrowed) locomotives to any train.

What does work is(a) complete separation of steam trains and Caltrain/HSR/non-FRA between San Jose and Santa Clara. It's feasible to fit 4 UIC and 2 steam train tracks here, with a bit of work and some very modest extra industrial ROW, BTW. And many orders of magnitude cheaper than tunnelling...

(b1) either GET RID OF THE DAMNED FREIGHT ALTOGETHER north of Santa Clara or(b2) keep some old Caltrain F40 diesel junkers, fit them out with ETCS, and require that they pilot any stream train heading up along the ETCS-required-no-exceptions corridor towards SF. If it takes a Caltrain loco on both the front and the back (like the BS the FRA requires of the Cascade Talgos) in order to proven train integrity to the signal system, well, so be it. (Not required by ETCS-2, just FYI. That's what axles counters are for.) That's all still going to come out hundreds of millions of PUBLIC DOLLARS cheaper than anything involving CBOSS or FRA PTC.

The solution is simple enough.The FRA NPRM appears to even allow such a scheme. (Probably an oversight!)

Get rid of the steam trains as much as possible, and, if there are any regrettably remaining, wrap them up in a nice cocoon of Caltrain Short Line ETCS bubblewrap.

Yes, simple enough. But clearly it's not Special Enough. Because we're Caltrain. And we have Special Needs. So go away!

Richard, in defense of consultants and contractors, I think you are raging against the wrong people.

The situation here is that the scope of the work is set by the same people who will be doing the work--a clear conflict of interest.

The problem is that public agencies responsible for wisely spending our tax dollars have unwisely abdicated their responsibility. If you're looking to place blame (and I'm not even sure that helps) then that's where I'd start. If you're going to engineer value, then the people holding the purse strings better have their own in-house expertise that is not beholden to any contractor in order to make a fair determination of whether they are getting value for our money.

When everything is outsourced, this model breaks down with familiar consequences. You can't blame contractors and consultants for doing what is fundamentally in their business interests.

What needs to be removed is the moral hazard: agencies that spend hundreds of millions of dollars on things they know nothing about.

Richard, you can get away with calling Amtrak steam trains. But UP is a profitable freight carrier, which probably carries more ton-miles than all European freight railroads combined.

You could make a case that NS and BNSF are right and UP is wrong, and electrification would not harm railroad profitability. But to call UP a steam railroad for not operating according to European standards is too much. On some issues, like cellular technology and passenger rail, the US is 50 years behind Europe. On others, like intermodal freight rail, it's 30 years ahead.

Freight on the SF peninsula is an irrelevance and a distraction. (Far worse than that, but let's try to be charitable.)

Perhaps from New Jersey it's hard to separate out UPRR, the continent-spanning coal-hauling behemoth, from the one or two make-work freight shuttles trains on San Jose to San Francisco line, the tiny little, insignificant piece of railway track north of San Jose which is the ostensible subject of this blog, but I assure you that from a much closer perspective they appear quite different. And the profitability or wisdom or volume of UPRR's haulage to and from Chicago or the Port of Oakland has nothing whatsoever to do with 99% of the traffic on the San Francisco Peninsula.

The Peninsula line doesn't have much freight, granted. But there's a long way from there to trying to ban freight trains north of Santa Clara.

As a resident of New York I can tell you that even regions with minimal freight rail sometimes try to improve their freight networks to take trucks off the road. Some of the local representatives are trying to fund a tunnel under 6-7 kilometers of harbor water so that freight trains can cross the Hudson near New York, whereas today the nearest crossing is in Albany. And yes, this constrains passenger rail planning a little bit.

The trick is to come up with ways to make freight constrain passenger rail planning less. Pressuring UP to electrify Peninsula freight is one way. Minimizing grade changes for the new Caltrain corridor is another. Banning freight is the passenger rail equivalent of UPRR's anti-HSR hostiliry.

Mlynarik will say that something (running freight, running a train through Los Banos every 7 minutes, running every train to SF, impeding Caltrain, using expensive passenger stations to park out of service trains, building 14 track stations, building four tracks all the way from SF to SJ, etc, etc) has real costs and that somebody should consider either not doing that thing or seek alternative ways to do it or do less of that thing to bring it below some cost or pain threshold. He'll also say that PBQD and Quentin Kopp are criminals with long histories of fraud.

Levy will say that something has a non-zero utility and therefore it should be done. And besides SNCF does it. Or appears to do it. Therefore it has no cost and has unlimited benefit and therefore it must be done.

Repeat.

It's pretty much what we always see in all these "transit activist" circles (to which none of the big boys, who care only about spending money, and don't care in particular on what, pay any attention.) Somebody says that maybe buses don't suck all the time and we should consider not building a train or streetcar line between every two points on the map. Somebody else says that buses are awful and Peak Oil is coming and General Motors killed the streetcars and surveys say people like trains more than buses and diesel kills babies and therefore we need to build a new train line.

Adding to the acronym hell is Hollysys, a Chinese company. It just secured SIL4 certification from for its ATP (automatic train protection) product, the core safety function of its train control system TCS which in turn is designed to work hand in glove with its Train Control Center (TCC).

While even the newest generation of this proprietary solution is only certified up to 300km/h, it's probably cheaper than competing solutions from European vendors.

I'm not sure what to make of the fact that Hollysys, a Singaporean company, has never gotten a contract in Singapore, or for that matter any other country where railways work. China, where the government ran the CRH on Beijing-Tianjin at higher speeds than are safe in order to impress foreigners, isn't a good model for California to follow.

Besides, if the system can't do 350, which is what California needs, then it's not worth much.

Over time I think it is quite safe to predict that 320+kmh commercial speed is going to be proven to be a bit of a technical stunt.

Technically feasible? No doubt at all.

Fast than 300? Yep, got that one covered. Faster than Amtrak, also.

Useful for schedule recovery? Yes, and perhaps 350 top speed will remain available for limited use indefinitely for that reason.

Economically or environmentally sustainable as a sustained operating speed in the medium or long term? Unlikely. Not here, and not elsewhere in the world.

And yes, I know all about how $200/barrel oil will make air travel more expensive. Preach to the choir! It will also make electricity and all the other essentially fungible energy sources, more expensive, and in the long run there are severely diminishing returns for the small time savings and large energy costs of 300+ speeds. It's about 100 times as cost effective to repair outright avoidable idiocies like Transbay or the San Bruno curve or operating HSR Redwood City-Santa Clara or pretending HSR is going to operate at 350 through the middle of central valley towns than it it to try to sustain the very highest speeds.

Summary: doing stuff has costs, and doing the most expensive stuff generally can't justify the cost.

It's not a wet dream - new high-speed lines are built to 350 all the time. Korea and Spain both plan to upgrade to 350 in the future, Japan wanted to do 360 but ran against curves and tunnel boom concerns...

The problem is that even with Pacheco (which, for all its other faults, is the fastest LA-SF option), to do LA-SF in 2:40 the average speed needs to be 267 km/h. There are segments in the world that achieve this average speed with a top speed of 300, but they don't have long slow zones near major cities or mountain crossings.

Now, from an environmental perspective, it'd be better to go for the Swiss solution - keep road tunnels under the mountains to a minimum, and toll the hell out of them; put all of your cities in an area compact enough to make 200 km/h a viable top speed. But since I-5 and I-80 have already been built and are toll-free, and LA and SF are not close enough for 200, that solution won't work for California. That's where the French or Japanese solution - make the trains go as fast as practically possible - comes in.

See, Alon, Southern Pacific built the first bridge crossing of the Bay in 1910 for two specific reasons. One, the Dumbarton Rail Bridge was the easiest crossing of the Bay where it is relatively narrow and shallow. Two, it improved access to San Francisco for its transcontinental traffic that crossed over Altamont Pass. Even the 19th-century private railroads once considered Pacheco Pass and rejected it.

SF-LA times are fastest by using the Dumbarton Rail Bridge and Altamont Pass. Check it!

It's criminal that Dumbarton Bridge is neglected as BART is extended to a failed automobile factory in Warm Springs.

If ERTMS is deemed to be too expensive, complex, and balise-based, they should go with ACSES-compatible signals.

It has the advantage over a custom system of being(1) functioning and installed in the US, avoiding the very troublesome development curve for new safety systems;(2) freight railroads already working with it, making an easier 'sell';(3) two independent implementations of essentially the same system (ACSES by Amtrak, and an intercompatible system from a different vendor by NJT), making for decent pricing;(4) Already handles everything which CBOSS is proposed to handle, including such weirdness as grade crossings and movable bridges.

It is a mistake to invent a new safety system unless you really do have billions and year to blow on it (as the Europeans did when they started developing ERTMS). The choice should be between the de-facto standard NEC-and-connected-lines signals and the ERTMS signals.

"The problem is that even with Pacheco (which, for all its other faults, is the fastest LA-SF option)

No, it isn't.

Even the EIR (with its optimistic Pacheco speed profile) says so."

Uh, no. I read the EIR. It explicitly says that the Pacheco route is faster for LA-SF than the Altamont-and-round-San-Jose route.

The across-the-bay route on the Dumbarton Bridge, while theoretically pretty good, is unusable, because CAHSR requires double track and the bridge is single track.... and building a wider bridge through a protected wetland -- and the Dumbarton bridge goes through an area protected by *multiple overlapping* sets of regulations -- is damn near impossible. Specifically, while putting a new bridge in on old footings or footings in the same location might pass environmental review, the new footings needed for a wider bridge would *never* pass environmental review.

And *even if it were possible*, due to the curve-based speed restrictions on the Altamont route, it wouldn't end up being significantly better than the Pacheco route. (*For passengers* -- for freight, grade dominates rather than curves, and the Pacheco route would have sharper grades with its shallower curves.)

Altamont is faster than PachecoAltamont is faster than PachecoAltamont is faster than Pacheco

Can we stop arguing about Altamont already? The reasons it were rejected have been rehashed over and over again. That decision is not changing. Posting anonymously on every article complaining that Altamont was better is getting pathetic.

And trust me, I'd rather it was going over Altamont too, but for purely selfish reasons in that I have family and friends in Pleasanton and Livermore, so that would make it easier for me to go see them. But from an operations and constructability standpoint, it's an inferior solution to grade separating and electrifying the existing caltrain ROW.

Even if Altamont is 2 minutes faster than Pacheco, its speed comes from the fact that it gives trains more time in the Central Valley, with its 350 km/h speeds. The route is longer than Pacheco, which would make top speeds of 350 even more important for maintaining an acceptable runtime. If trains have to slow down in the CV then both Pacheco and Altamont will take longer, but for Altamont the time penalty will be much higher.

Anon: the point of my post was to talk about top speed, not about Altamont vs. Pacheco.

But while we're on that subject, the 2:36 base case for LA-SF assumes that HSR will be able to use the UP right-of-way through Merced and Modesto. This is unlikely; it's much more likely HSR will need to use the BNSF right-of-way, which is further east and would take longer.

However, I'm happy to admit that if UP decides that HSR is teh awesome, Altamont will be faster than Pacheco.

Alon, a much better ROW is available in the Central Valley: the I-5. Then the Altamont route would be much faster than the Pacheco route. I mean, if you want to get into the fastest routes, let's actually consider the fastest and most efficient.

It's better to have shorter routes with slower trains than needlessly long routes that require energy-hungry faster trains on capital-intensive infrastructure to make up the time penalty.

Clem - I'm with you. It's just that when it got into personal attacks I felt like defending myself from, well, whichever Anon who got pissed.

Caltrain First - I don't want to get into I-5 versus SR-99. But even with I-5, which saves maybe 10 km, there's no way of doing LA-SF in under 2:40 without an average speed of about 260, which requires a top speed of 320-350. About the only way you could do LA-SF in 2:40 with a top speed of 300 would be to use the Grapevine and a new Transbay Tube, which is too expensive.

Regarding grade crossings: With ETCS 3.0.0 the driver's cab receives information regarding upcoming grade crossings, how they are secured and how to pass them. But it's not (yet?) a two-way communication.

Great blog. Some very down-to-earth practical engineering policy ideas here, I hope some cut through the politics. A comment- ETCS is not so much an "off the shelf train control system" as "off the shelf platform". The operating rules and the railway's signalling standards into which ETCS is laid are as, if not more important than the technology itself. The extent to which this is true varies depending on the level, e.g. in a Level 1 system, ETCS is little more than an ATP supervisor of the existing system. In ETCS Level 2, it could be augmenting wayside signals, or can replace them. Your fundamental detection (track circuit) configuration, interlocking, route setting etc does not necessarily change because of ETCS levels 1 or 2, though in a big investment phase it would be a good time to review these things. Really a full scale review of signalling principles (such as that in the Institution of Railway Signalling Engineers 2001 "Signalling Philosophy Review" of UK signalling principles) is an important starting point. There could be a whole host of issues with how existing signalling principles and practices impede capacity, performance etc in a new technological paradigm.

Also re the history of full cab-signalling and Automatic Train Protection, here's a little curio for you from very close to home. Indeed from the approach to the Transbay terminal almost 70 years ago. http://www.youtube.com/watch?feature=player_detailpage&v=rhGKOLgu7Wg#t=530

First ETCS Level 2 signalling and telecommunications contract in North America:https://www.thalesgroup.com/en/worldwide/transportation/press-release/mexico-thales-wins-first-etcs-level-2-signalling-and