CBOSS Dumpster Fire Update

The CBOSS development lifecycle,
as anticipated in 2009 on this blog.
Today we are at "point of no return."

The deadly crash of an Amtrak train near Tacoma, Washington, which would likely have been prevented if a PTC (Positive Train Control) system had been in place, has renewed the discussion of the status of PTC systems in the Bay Area. Caltrain officials say everything will be OK with CBOSS, Caltrain's very own flavor of PTC. Despite those assurances, a potent brew of ingredients is mixing together.

Bonfire of Lawsuits: After a well-chronicled program failure involving delays, cost overruns, and failure to meet milestones, Caltrain terminated the CBOSS prime contractor, Parsons Transportation Group, in February 2017. PTG and Caltrain promptly sued each other, with PTG claiming wrongful termination and Caltrain seeking up to $98 million in damages. A rich trove of documents can be accessed online under San Mateo Superior Court case number 17CIV00786, and chronicles in detail everything that went wrong with the CBOSS program. With Caltrain likely to recover some damages, PTG has now sued Alstom (formerly PTG's subcontractor and the supplier of CBOSS hardware and software) for failure to deliver a working solution. One is left to wonder how this motivates Alstom to finish the CBOSS project, since delivering a working solution to Caltrain would undermine the claim that Alstom was given an impossible task.

Dying Product: The hardware and software underlying CBOSS is known as I-ITCS, a product originally developed by GE Transportation Systems Global Signalling. While a precursor known as ITCS briefly operated on Amtrak corridors in Illinois and Indiana, it is now being displaced by the de-facto standard freight PTC system known as I-ETMS, with ITCS relegated to controlling only the grade crossing functionality in these corridors. Alstom, which acquired GE Transportation Systems in 2015, is not likely to see a future in the I-ITCS product, leaving Caltrain with a globally unique hardware and software solution. This does not bode well for product support over the lifetime of CBOSS.

Looming Deadline: the deadline imposed by Congress and the Federal Railroad Administration to successfully complete a PTC revenue service demonstration is just a year away, at the end of 2018. One year is not enough to finish, and Caltrain will almost certainly blow this deadline. Will FRA grant another extension and allow Caltrain to continue operating without PTC?

Sole Source Savior: in July 2017, avionics firm Rockwell Collins' subsidiary ARINC was awarded a sole source contract to figure out what it will take to pick up the pieces and complete the CBOSS project. ARINC completed this assessment in September, and will soon (by sheer programmatic necessity, since failure is not an option) be awarded a name-their-price sole source contract to finish a minimally working version of CBOSS that passes FRA muster. With the leverage that ARINC enjoys under these circumstances, the "re-procurement" of CBOSS will likely be (1) expensive and (2) structured such that Caltrain bears all of the risk of continued failure, i.e. cost-plus-fixed-fee rather than fixed price. With the clock ticking, the re-procurement effort has already fallen behind the planned fall 2017 schedule.

Budget Crunch: To date, Caltrain has spent over $200 million (yes, one fifth of a billion dollars!) on CBOSS with nothing to show for it. All the money allocated for CBOSS is spoken for, and a lot more (several tens of millions) will be needed to finish the project. Some of that will come from damages, but it is quite likely that 2018 will bring emergency financial maneuvers to throw more good money after bad.

Descoping of Functionality: while the first 'I' in Caltrain's I-ITCS solution stands for "Interoperable," which was one of the original selling points of CBOSS, this feature is now being thrown over the transom. Interoperability requirements contributed to the scope creep that triggered a re-design of the supposedly off-the-shelf ITCS software. It didn't help that Union Pacific was (as per usual) actively non-cooperative in helping to develop an interoperable solution, leading to Caltrain throwing in the towel and spending an additional $21.7 million (from an FRA "interoperability grant," no less!) to dual-equip seven diesel consists with the I-ETMS freight PTC system for operating on the Gilroy branch owned by UPRR. How I-ETMS freight trains will be accommodated on the peninsula corridor in I-ITCS territory is a burning question, for which the range of answers includes ditching I-ITCS and replacing it with the more viable I-ETMS, following the Amtrak example.

System Integration and Testing is Hard: while Caltrain never fails to remind us that all of the components of CBOSS are physically installed on the trains and the tracks, that is the easy part. The hard part is getting everything to operate together reliably every day, and Caltrain and their shifting band of contractors are barely getting started on this most difficult phase of the development of a new and complex safety-critical system. Integration and Testing is where the best design intentions meet cold harsh reality, and all the mistakes and omissions made during the design phase become painfully apparent. While PTG claimed in court filings that they were 90% done with CBOSS when their contract was abruptly terminated, that last 10% of troubleshooting commonly takes far more than 10% of the budget or schedule.

PTC is Hard: the legal declarations from PTG managers who ran the CBOSS program (see 17CIV00786) reveal a long list of underlying factors that caused much acrimony and remain unchanged today: (1) the specifications and standards for PTC continue to evolve, triggering continued changes and penalty testing; (2) Caltrain and its in-house consultants (the so-called "owner's team") are woefully ill-equipped and uncoordinated in their approach to complex safety-critical avionics technology development; (3) the formal contractual interactions between the "owner's team" and the vendor are complicated and delay-prone; (4) working with UPRR is a huge pain in everyone's caboose; (5) the underlying systems over which CBOSS is supposed to "overlay" are kludged-together stove pipes that, incidentally, will require nearly total re-design for the electrification program; (6) testing PTC on an operating railroad requires extensive coordination that has been demonstrated to be lacking; and so on. Strike PTG and substitute ARINC.

These ingredients will produce a situation where CBOSS does less than was promised, later than planned, and for a lot more money. No crystal ball is needed to predict that CBOSS will continue to "fail forward" to a finish line somewhere beyond 2018.

Steaming Pile of CBOSS

CBOSS, the Communications Based Overlay Signal System, is a Positive Train Control (PTC) system being developed by Caltrain to prevent human error from killing or maiming passengers or rail workers.  It is a deeply troubled project.  Caltrain recently requested a peer review of the project from APTA, the American Public Transportation Association, whose subject matter experts were given access to personnel and documents.

Download the final report from the peer review here (500 kB PDF).

It's fair to say our worst fears have come true:

• the project manager does not have the requisite technical experience
• there is no project schedule, and October 2016 is just another month on the calendar
• inter-operability requirements and test methods are not defined or agreed upon
• configuration management is not just out of control, but completely lacking as a process
• software and network security is an afterthought
• animosities between project management and the contractor are impeding the resolution of technical issues
• operator training has not started, and the materials for such do not yet exist
• weekly top-level status meetings between Caltrain management, the program management consultant, and the contractor had not been occurring

The list of documents reviewed by the panel in Appendix C would make a juicy FOIA request.

A little bird overheard some discussions that do not appear in the APTA final report, because the report is intended to provide only constructive criticism to help Caltrain out of this mess.  It's even uglier than you could have imagined:

• Parsons Transportation Group (PTG), Caltrain's prime contractor, does not have the right skills mix to manage complex system integration on 13 different subcontracts
• PTG is fearful that the commercial terms of the CBOSS contract expose them to legal action by Caltrain, contributing to the lack of transparency
• Subcontractor General Electric (now Alstom) discovered that simply re-using the existing ITCS product wasn't going to work.  The inter-operable version of the product is incurring massive increases of scope that were not accounted for in the original contract
• Because of the extent of the changes made to ITCS, the FRA is requiring the same certification and type approval process as for a new PTC system, undermining Caltrain's claim to reusing an off-the-shelf technology
• The FRA has taken the position that Caltrain is really installing two PTC systems, requiring full testing of both I-ITCS and IETMS (the system that will be used by Union Pacific freight trains on the peninsula corridor)
• Inter-operability means not only allowing IETMS equipment to operate in CBOSS territory, but also allowing CBOSS equipment to operate in IETMS territory, something that Union Pacific has been concerned about testing thoroughly
• Poor coordination for accessing an operating railroad for system installation and testing has been and continues to be a bottleneck
• Additional funding is going to be needed, but nobody knows how much more
• A change of contract operator (currently Transit America Services, Inc, soon coming up for re-bid) would introduce significant program execution risk
• Getting all the CBOSS-equipped trains into revenue service could take up to 5 months

The already egregious sum of $231 million to cover a measly 51 route-miles with PTC is about to increase significantly, something you would never guess from the latest CBOSS update provided to Caltrain's laissez-faire board of directors.

Fast forwarding to whatever year it eventually takes place, the RSD (Revenue Service Demonstration) will consist of flipping the "on" switch and transforming rush hour into an epic cascade of software glitches reminiscent of the 1998 MUNI Meltdown.  On that day, we will all know that this CBOSS turkey has finally come home to roost, as was foretold way back in 2009.

Train Control Update

There have been two recent and important developments in the area of train control systems, the safety systems known in U.S. parlance as "Positive Train Control" or PTC.  Both of them have a direct impact on the future of the peninsula rail corridor.

CBOSS Goes Sideways

Caltrain's CBOSS project, criticized for years on this blog, is in ever deeper trouble.  According to Caltrain's latest project update, the $231 million previously allocated for this project are nearly spent, but the project is way behind schedule and struggling in the most perilous and delay-prone phase of all: testing of the integrated system.

Not Ready for FRA

Testing is where it all finally comes together, not in the carefully controlled environment of a lab test bench, but in the real world with all its ugly imperfections, annoying glitches, and external influences.  In each segment of the railroad, three things have to happen in sequence: (1) everything has to be fiddled with until it works; (2) when everything works, a dry-run of the official acceptance test, known as "Pilot Testing," is performed; and (3) the system is formally accepted after passing the official FRA-witnessed test of all its functions.  Caltrain's project is stuck in the "fiddle with it until it works" phase, helpfully diagrammed as an infinite loop in the test flow diagram at right, extracted from a CBOSS Verification, Testing and Inspection Plan filed with the FRA.  This is where the schedule and budget are blowing up, with Caltrain's next step described as "Complete Segment #3 Pilot Testing and FRA Witness Testing," coming as soon as they are "Ready for FRA," whenever that may actually be.

Caltrain's update mentions "software release delays" relating to the I-ITCS product that CBOSS is based on.  There are worrying signs that I-ITCS may become a technological dead end: the company that makes it, GE Signalling, was recently acquired by French rail giant Alstom.  Alstom's mainline signaling product portfolio does not give it top billing.  Furthermore, the FRA process is described as being "in flux", meaning that the goal posts are moving.

What we have here is a classic foundering IT project, and it isn't clear if throwing more money at it (at a burn rate of about $50M/year) is going to save it.  With the federal PTC implementation deadline now pushed out to 2018, this is a good time to stop and re-assess the project before escalating the commitment.

HSR Buys Radio Spectrum

Meanwhile, the California HSR Authority is about to spend $50 million to secure the rights to a key chunk of radio frequency spectrum.  The frequency bands being purchased are 757-758 MHz and 787-788 MHz, not the usual 220 MHz band used for freight PTC systems.  Instead, the CHSRA has documented its intent to deploy ERTMS, an increasingly mature and proven train control standard that originated in Europe and is increasingly in worldwide use.  The two bands purchased for HSR are not sufficiently wide to deploy GSM-R, the obsolescent communications standard currently used as part of ERTMS.  It is more likely that California's deployment of ERTMS will use a more modern, secure and spectrum-efficient LTE communications layer, following the evolutionary path beyond GSM-R already being planned for ERTMS.

Connecting the Dots

Suppose the following conditions come to pass:

1. CBOSS proves unworkable (increasingly likely)
2. HSR shifts its focus to Northern California (possible)
3. HSR finalizes plans for ERTMS as its high-speed train control standard (very likely)
4. Due to construction delays, HSR needs new and productive ways to spend federal funds that expire by 2017 (possible)

Then an opportunity exists to deploy a train control pilot project on the peninsula rail corridor, using ERTMS with LTE communications in the 700 MHz band.  This scenario recognizes an important fact so far disregarded by Caltrain, that HSR will become by far the largest tenant railroad on the peninsula.  Ignoring this fact is an odd position to take for a railroad that hangs its future on "blending" with HSR.  Caltrain will surely dislike the idea, bleating about closer headways, crossing signal integration, station stop enforcement and other completely unproven bells and whistles--as they have since 2009--but events are now quite clearly bearing out the relative technological merits of ERTMS and CBOSS.  It's just sad that it took a quarter of a billion dollars to settle the question.

In the unforgiving world of system integration testing, reality always wins.

CBOSS Headed for Trouble?

The button we may soon have
to press. Photograph by
Sander van der Vel

Caltrain's new Positive Train Control (PTC) system, known as CBOSS, appears to be running into serious technical difficulties just as the program enters its most challenging phase: testing and commissioning.

The system was originally proposed to be built on top of GE Transportation's Interoperable Incremental Train Control System (I-ITCS) technology, an approach that was touted as advantageous for being "off the shelf."  There are subtle signs that things aren't going so well:

• This month's CBOSS project status update states rather cryptically that the top challenge for the project is GE software release delays.  These delays could be related to the recent purchase of GE's Transportation arm by the French firm Alstom, which already offers a range of PTC technologies that could make the ITCS product line redundant.
• The technical requirements for the electrification RFP state (see PDF p. 251 of 2,840) that CBOSS is built on Wabtec's Interoperable Electronic Train Management System (I-ETMS), the main competitor to GE's I-ITCS.  Switching from ITCS to ETMS would be like changing the foundation of a house after the roof is completed.
• Section 4.13.1 of the electrification RFP document describes the electrification project scope, stating that "The Contractor shall provide the signal, train control and grade crossing systems"... a definition of scope that overlaps significantly with the CBOSS project.
• Section 4.13.3.1 of the electrification RFP document further describes items that are in the scope of the electrification program, including:
• System-wide track circuit replacement
• Manufacturing and assembly of signal enclosures, including installation and wiring
• Installation of signal enclosures, wayside signals, cables, and cable infrastructure
• Field testing of the signal system and integrated testing with the electrification, EMU, CBOSS/PTC and other interdependent systems
• All work associated with the modification of the signal system required for the Project, including the CBOSS/PTC system as necessary and as required by all regulatory agencies, including the FRA, MUTCD and CPUC. The Contractor shall ensure that its wayside CBOSS/PTC systems are 100% compatible with the existing CBOSS/PTC systems that its systems will interface with.
• The electrification RFP document continues for dozens of pages, describing how an almost entirely new signaling system will have to be installed as part of the electrification project.  What CBOSS was supposed to "overlay" will be largely replaced.

Is there a major architectural change in the CBOSS project that Caltrain staff failed to disclose to the board?  The entire CBOSS budget of $231 million (an astronomical sum for just 50 route-miles of railroad) having already been appropriated and mostly spent, are we about to see large cost overruns get squirreled away in the small print of the electrification RFP?  Is the respective scope of the CBOSS and electrification projects sufficiently well delineated to preclude spending money twice on the same item under two separate contracts?

A faint odor of fish wafts over the whole affair.

U.S. Supplier Enters ERTMS Market

In a move that amounts to a clear acknowledgement of the increasing worldwide supremacy of the ERTMS ("European" Railway Traffic Management System) technology standard, General Electric Transportation Systems recently became the first U.S. signaling supplier to enter the ERTMS market.

GE Transportation Systems is the same company slated to supply the on-board and wayside components of CBOSS, Caltrain's new-fangled train control system that will be paid for with HSR funding while being technically incompatible with the HSR train control system.

One could briefly entertain the illusion that common sense might prevail, and that with a minimum of contractual upheaval CBOSS could evolve into the first U.S. installation of ERTMS, a solution that could eventually be extended to the entire California HSR system.  Unfortunately, in the blinkered world of parochial agency interests, spending money (over $200 million of it for SF - SJ alone!) is a higher aspiration than providing a good technical solution.  Compatibility is for sissies; why do it right when you can do it twice?

ERTMS Coming To California

The CHSRA recently added to its collection of technical memos a White Paper on train control technology for California's high-speed rail system.  The selected train control system will likely be deployed on the peninsula rail corridor later this decade or in the early 2020's, regardless of what "solution" Caltrain may pursue in the interim.  The CHSRA's experts looked far and wide for the best technical solution, and as longtime readers of this blog may have guessed, they conclude as follows:

The sole technology that is fully compliant with all of the CHSRA project and technical requirements is the European Rail Traffic Management System (ERTMS) European Train Control System (ETCS) Level 2 with Global System for Mobile Communications – Railway (GSM-R). ERTMS is service-proven and its attributes are highly applicable to CHSTP automatic train control (...)

The biggest technical obstacle for importing ERTMS to the U.S. is the lack of available radio frequency spectrum.  The White Paper delves into great detail about possible ways to overcome this, making several important policy statements along the way:

• The choice of train control technologies will be limited to solutions that have been successfully demonstrated at high speeds for a period of at least 5 years, to minimize implementation risk and enable a strong safety case to be made to the FRA.
• The CHSRA requires that it not be locked into a single source for procurement, bidding, and supply. Interoperable, interchangeable, open standard and multi-vendor solutions are required and will provide the CHSRA with several sources of supply for extensions, upgrades, and maintenance spare parts in the present and future, thereby lowering risk and cost. (Are you listening, Caltrain?)
• Other alternatives to ERTMS are not technically compliant, not compliant with the project requirements, or present too much risk to implementation.

As it happens, the coveted ERTMS / ETCS Level 2 is transparently compatible with ERTMS / ETCS Level 1, which the White Paper describes as follows:

ETCS level 1 is designed as an add-on to or as an overlay on a conventional line already equipped with wayside signals, and possibly as a fallback solution from ETCS level 2. Communication from the track to the train is ensured by dedicated balises located on the trackside adjacent to the wayside signals at required intervals, and connected to the nearby interlocking and/or wayside signals.. The balises have a data connection to the ATC equipment which provides movement authorities for transfer to the train. Receiving the movement authority through balises, the ETCS onboard equipment automatically calculates and indicates to the train engineer maximum permitted speeds of the train and the next braking points if needed, taking into account the train braking characteristics and the track description data. This information is displayed to the train engineer through a dedicated screen in the cabin. The speed of the train is continuously supervised by the ETCS onboard equipment.

This is of course precisely the same thing as CBOSS, which Caltrain and their vendor Parsons Transportation Group are now kludging together for us for a hefty wheel-reinvention fee.

We've already seen Caltrain work with FRA bureaucrats to avoid re-inventing a double-deck EMU train.  Why can't they also work with CHSRA, FRA and FCC bureaucrats to avoid re-inventing a train control system?  The CHSRA is already putting together a plan for scaling the regulatory mountain, with more detail on radio frequency spectrum acquisition provided in TM 300.03 EMT Radio Frequency (RF) Spectrum Acquisition Strategy.

It's no longer just a blogger saying it (bloggers don't know what they're talking about): the high-speed rail project is now firmly on the record as preferring ERTMS as the sole solution, and is already working with government and private entities to obtain the necessary radio spectrum to deploy GSM-R in California.  ERTMS is the best solution for the peninsula, because it would allow high-speed trains to use Caltrain tracks with no special equipment or modifications.  As a side benefit, it would also allow Caltrain to meet their PTC requirement at minimal cost and risk.

ERTMS is coming.  Your move, Caltrain.

Meanwhile, in Rio...

It finally happened.

Last Thursday, Caltrain's board authorized the award of the first phase of a $138,135,673 contract to Parsons Transportation Group to design, procure and install the Caltrain-specified CBOSS train control system (see staff presentation).  This Parsons contract forms the lion's share of a total project budget variously reported as $231 million to $251 million, or a whopping $5 million per route-mile.  According to a project schedule, the final acceptance of the system is planned for February of 2016 (52 months from now), but that assumed contract award at the May board meeting (5 months ago).

Viewed in the framework of the U.S. transportation industrial complex, where public agencies such as Caltrain transfer huge sums of taxpayer dollars to large private corporations that thrive on custom-engineering, re-engineering and over-engineering everything, this contract is business as usual, and Caltrain will probably end up, years late and millions over budget, with a partially functional PTC system.  That sets the stage for more years and millions spent to make it work with high-speed rail.

Meanwhile, in Rio...

Meet SuperVia, a commuter rail operator in Rio de Janeiro, Brazil.  SuperVia is one busy system, even busier than BART.  Here's a quick comparison between Caltrain and SuperVia:

	Caltrain	SuperVia
Route Miles	77	140
Routes	1	5
Trains	about 25	about 160
Stations	31	89
Weekday Ridership	~45,000	~540,000

Like Caltrain, SuperVia is modernizing.  Among other improvements, SuperVia is installing a sophisticated positive train control system to enforce speed limits, prevent collisions, and reduce the headways between trains.  Unlike Caltrain, SuperVia chose to adapt their requirements to what suppliers already had on the shelf, and is procuring an ERTMS Level 1 overlay system from Bombardier Transportation through a contract worth 125 million Real, or about US $70 million.  (Note that the unknown scope of this contract makes it difficult to compare directly to CBOSS; for example, Bombardier's contract is unlikely to include the train-borne components.)  ERTMS, to remind everyone, is a train control standard that is quickly catching on worldwide, except here in the protected U.S. signaling market.

ERTMS Level 1 is exactly the sort of standardized train control system that would be transparently compatible with high-speed rail, which will most likely operate on its own dedicated high-speed trackage using ERTMS Level 2, a much more sophisticated version of the standard that does away with wayside signals.

The kicker?  Bombardier promises to put this new overlay signaling system into service on SuperVia's various lines from November 2012 to July 2013.  Here's how that stacks up against Caltrain's CBOSS:

	Caltrain CBOSS	SuperVia ERTMS
Contract award	October 2011	May 2011
Initial service entry	October 2015	November 2012
Final delivery	February 2016	July 2013
Time from award to initial service	48 months	18 months
Time from award to final delivery	52 months	26 months

It's too late now to do anything about CBOSS, but it sure will be interesting to see what PTG and Bombardier will deliver for each respective rail system.  Can PTG and Caltrain come up with an ersatz-ERTMS by 2015 for the promised sum?

The Truth About CBOSS

$16 million was recently awarded by the FRA for the CBOSS project, Caltrain's Communications-Based Overlay Signal System. Caltrain CEO Michael Scanlon states in a Caltrain press release: "This initial federal investment will enable Caltrain to take an important step forward in our efforts to provide Bay Area communities with a modernized, sustainable commuter rail system that is fully compatible with future high-speed rail service". His counterpart at the California High-Speed Rail Authority, Roelof van Ark, intones in a CHSRA press release: "This latest step forward in federal support for California’s project means that we’ll be able to improve safety and service in the near term and integrate our project with local systems in the long term."

Fully compatible with high-speed rail service? Integrate HSR with local systems? Really?

Let's take a closer look. As regular readers know, CBOSS has often been criticized on this blog. Rather than rehash extensive previous commentary on CBOSS, let's rely on cold, hard facts obtained solely from primary source documents. You get to decide!

The Evidence

Exhibit A: Caltrain CBOSS Request For Proposal Package, Questions Received and Answers No. 3, dated 6 October 2010. Question #20 from a prospective bidder: "What assumptions should me made in terms of HSR? (Interoperability, Operations, sharing track, etc.)" The answer from Caltrain: "Under current RFP Scope of work, HSR Operations is not considered for this phase of PTC implementation."

Exhibit B: Caltrain CBOSS Request for Proposal Package, Questions Received and Answers No. 4, dated 9 October 2010. Question #16 from a prospective bidder: "Part 2, Section 3, Exh B, Spec 21001, 1.03D requires the system to be interoperable with California HSR signaling. HSR is undefined at this stage. As this solution is not known, Contractor cannot assess any effort associated with this interoperability requirement. Please clarify how Contractor should assess." The answer from Caltrain: "Interoperability with HSR signaling is not part of the Scope of work for Caltrain PTC system RFP."

Exhibit C: Caltrain CBOSS Request for Proposal Package, Questions Received and Answers No. 6, dated 15 October 2010. Question #31 from a prospective bidder: "The RFP addresses HSR. What assumptions should the proposer make in order to address HSR requirements?" The answer from Caltrain: "Evaluation of the potential for the proposed solution to meet future HSR needs will not be part of the proposal evaluation."

Exhibit D: Caltrain's Positive Train Control Implementation Plan, a 183-page document required by law to be submitted to the FRA and detailing how Caltrain will implement its new signaling system, mentions HSR exactly once in the introduction on page 1-1. That's a slight improvement over a previous revision of the document, rejected by the FRA, which did not mention HSR at all. Section 5.1 of the document, discussing Interoperability with other railroads, does not mention or discuss HSR. Appendix D, containing letters of understanding to coordinate PTC implementation with other rail entities, does not include the CHSRA.

Exhibit E: Caltrain's Positive Train Control Notice of Product Intent, a 50-page document that describes how CBOSS will operate, explains in Appendix A section 12 the interoperability with other rail entities. Out of five paragraphs, four mention the Union Pacific, and zero mention California high-speed rail.

Exhibit F: The California High-Speed Rail Authority's extensive collection of technical memos includes Technical Memo 3.3.1, released 25 June 2010, detailing the concept of the system that will be used to control trains on the high-speed rail network. Section 1.2.4, Automatic Train Control Specification Requirements, states "The prime requirement for the CHSTP ATC system is that the technology must already exist as part of an operating system with proven experience worldwide on at least one high speed passenger railway." CBOSS clearly does not fall into this category, which means CHSRA will necessarily use another train control system than CBOSS on its own tracks.

Serious Questions

In light of all this evidence, the happy talk about CBOSS paving the way for HSR rings hollow, and raises some serious questions:

• Is the Caltrain leadership (board and CEO) even aware of the details of the program being carried out by staff and consultants? Do they know that interoperability with HSR is explicitly excluded from the CBOSS RFP?
  
  
• What is the plan for making CBOSS interoperable with HSR? Might it make sense to develop such a plan before awarding the CBOSS implementation contract, which may happen in the next couple of months?
  
  
• Does the $251 million budget for CBOSS include the cost to make CBOSS interoperable with high-speed rail, as specifically excluded in the current RFP, or will taxpayers be asked for even more money?
  
  
• Does the Caltrain and CHSRA leadership (respective CEOs and Boards) know that California HSR is slated to use a different train control system than CBOSS?
  
  
• If California high-speed trains will use another train control system than CBOSS, why is federal HSR money being spent on the development of CBOSS? Can or should Caltrain expect HSR monies to cover the remaining 90% of the CBOSS cost that is not yet funded?
  
  
• How, why and when were existing train control technologies, such as ERTMS, the standard that shows the strongest signs of being favored for HSR in California (see TM-3.1.1 section 6.1), eliminated from consideration on the peninsula corridor?
  

The local press has spent numerous column-inches, sometimes even two-page spreads, covering the Caltrain CEO's compensation package. But this is $16 million we're talking about, heading rapidly for $251 million. And not a peep from the press.

Staking Out CBOSS Territory

All railroads that will be deploying Positive Train Control (PTC, read all about it here) before the mandated deadline of 2015 were required by federal law (49 CFR Part 236 Subpart I) to submit a PTC Implementation Plan by April 16th, 2010. This plan, subject to FRA approval, is where each railroad explains how it plans to deploy PTC.

Caltrain's PTC Implementation Plan (4.5 MB PDF) was submitted in late March, and is available to the public under docket FRA-2010-0051.

Not surprisingly, the centerpiece of Caltrain's PTCIP is the Communications-Based Overlay Signal System (CBOSS), a new PTC system that Caltrain is developing. CBOSS, described in a Caltrain fact sheet, is about to go out for bid. The importance of this system cannot be overstated, since the additional safety it confers on Caltrain's operations are a prerequisite for the transition to a new fleet of electric trains as well as the extensive reconstruction of the peninsula corridor to accommodate high-speed rail. PTC is a necessary step on the path to reinventing the peninsula corridor, and lies squarely in the schedule's critical path--never mind any federal deadlines. There remains a significant amount of doubt about whether Caltrain can actually pull it off.

Planning For Interoperability

By law, a PTCIP is supposed to describe in some detail how the proposed PTC system will provide interoperability between the "host railroad" and all "tenant railroads" that use the host railroad's tracks. Accordingly, Caltrain lists the following tenant railroads: Union Pacific Railroad, which operates a few freight trains on the peninsula; Amtrak, which operates the Coast Starlight along 6.7 miles of Caltrain's tracks through San Jose and Santa Clara; the Capitol Corridor JPA, which operates Amtrak California trains along 2.6 miles of Caltrain's tracks; and the San Joaquin Regional Rail Commission, which operates the Altamont Commuter Express trains along 2.6 miles of Caltrain's tracks. According to the PTCIP, the entire volume of traffic from all tenant railroads is currently 24 trains per day.

The stunning omission from Caltrain's PTCIP is any mention of high-speed rail. HSR is not mentioned even a single time anywhere in this 123-page document.

While HSR will not be anywhere near entering service by the PTC deadline of December 31st, 2015, the technical interoperability issues with high-speed rail are of paramount importance. HSR is the ultimate "tenant railroad" since it plans to operate on the order of 200 trains per day along the entire length of the peninsula, as opposed to 24 trains per day, most for only 2.6 miles between San Jose and Santa Clara, for all other tenant railroads combined. The ratio of train-miles operated on Caltrain territory for HSR vs. all other tenant railroads will be nearly two orders of magnitude as shown in the chart at left!

Looking at the chart might elicit an important question: with which "tenant railroad" will it be most important to interoperate? The Caltrain PTCIP provides the answer, point blank: the Union Pacific Railroad (see section 5.2), shown in yellow on the chart. That's right, because of an assumption that UPRR cannot be bothered to fit additional PTC equipment on the handful of its locomotives that operate on the peninsula, or an assumption that HSR may never come to fruition, CBOSS must be designed to be 100% compatible with whatever technology UPRR comes up with by 2015. There are two possible outcomes to this approach:

1. The entire statewide fleet of high-speed trains will need to be fitted and certified with a separate set of CBOSS train-borne equipment for operation on Caltrain's tracks because the HSR PTC system will be inoperable in "CBOSS Territory", or
   
   
2. The peninsula corridor will be segregated into technically incompatible HSR tracks and Caltrain + freight tracks, each with its own PTC system.
   

Neither of these outcomes is good for state or federal taxpayers, and the latter is a disaster for the train riding public. Both outcomes are quite profitable for the companies that will design, build, deploy, test, certify and operate the respective PTC systems on the taxpayer's dime.

One would think that enough time has passed since November 2008, when the high-speed rail bond was approved by California voters, to develop at least an inkling of a plan for how HSR will mesh with Caltrain in the area of PTC. One would further expect that Caltrain's insistence that the peninsula corridor will be a fully-shared four-track system would cause it to pay special attention to questions of future interoperability with HSR. One would even further expect that the California High-Speed Rail Authority's apparent plan to use ERTMS (an existing European PTC standard that has similar functionality, but is different from CBOSS) would at least be acknowledged in Caltrain's PTCIP.

Is this a lack of attention to detail? Evidently not: Caltrain's PTCIP goes into considerable detail on how individual PTC hardware components will be mounted on its locomotive fleet, as evidenced by the photo at right. The photo, included in an Appendix of the PTCIP, shows an early prototype of a CBOSS Central Display Unit (at the same stage of development as the CBOSS software) being fitted to the cab of a Caltrain locomotive. What is most visible in this photo is attention to the wrong details, details that are trivial, while other enormously important issues are seemingly entirely overlooked.

If one requirement of a PTCIP is to describe how a PTC system will provide interoperability of the system between the "host railroad" (Caltrain) and the ultimate "tenant railroad" in the form of high-speed rail, Caltrain's PTCIP has fallen woefully short.

What is the plan?

First Nail in the CBOSS Coffin

Buried deep in the CHSRA's March 3rd Operations Sub-Committee meeting, in a progress report briefing prepared by the Program Management Team (Parsons Brinckerhoff), are the following little gems (boxed in red):


The acronyms ERTMS, ETCS and GSM-R refer to the European Railway Traffic Management System and its components (the European Train Control System and the GSM-Railway cell data standard). The completion levels for these documents suggest that ERTMS has already been selected as the train control technology for the California High Speed Rail System. Quite wisely, the project appears to have selected an off-the-shelf technology standard that was developed and debugged using billions of Euros of OPM (Other People's Money).

Meanwhile, spunky little Caltrain continues to believe it can single-handedly develop an entirely new train control technology known as CBOSS (Communications-Based Overlay Signal System), which is functionally redundant with ERTMS / ETCS. (For more background about these technologies, see Peninsula Train Control: PTC, CBOSS and ERTMS.)

The design, integration, testing, and deployment to commercial service of CBOSS is estimated to cost $231 million, before the cost overruns and schedule delays inevitably associated with this type of development effort. While some of this funding was expected to come from the $2.25 billion California HSR stimulus award, how likely is the CHSRA to fund the CBOSS project if it has already selected ERTMS for itself?

Caltrain needs to wake up and stop striving for compatibility with freight PTC. The correct solution is to abandon CBOSS, join forces with the CHSRA to bring ERTMS to the United States, and implement an integrated Caltrain / HSR train control system. Navigating the bureaucratic hurdles of importing ERTMS, ETCS and GSM-R is likely to be far quicker, easier and cheaper than trying to re-invent the wheel with CBOSS. That's especially important because Caltrain's fleet replacement effort cannot proceed until after a robust train control solution is in place. The clock is ticking as Caltrain's antiquated diesel trains fall further into obsolescence, and failure is not an option.

This appears to be the first nail in the CBOSS coffin.

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.
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. 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.
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.
  

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.

Regulatory Vacuum

Preliminary design for the California High Speed Rail project is proceeding in the absence of key regulations from the California Public Utilities Commission (CPUC), the Federal Transit Administration (FTA), the Federal Railroad Administration (FRA), and numerous other agencies. While high speed rail is a very mature technology, it is still foreign and exotic in the United States, and our regulatory agencies do not yet have an effective or complete regulatory framework in place to direct the development of high speed track and trains. The regulatory vacuum is already causing some strange and potentially regrettable design decisions to be made, with negative consequences for the peninsula corridor.

Platform Heights

The side clearance dimensions around passenger rail platforms in California are regulated by the CPUC under General Order No. 26, originally issued in 1948, covering every relevant railroad situation from stock chutes to icing refrigerator cars. Where freight trains share tracks with passenger trains, as they do on the peninsula corridor, G.O. 26 limits passenger platforms to a height no more than 8 inches (203 mm) above the top of the rails (ATOR) to allow trainmen to ride on the side of freight cars without fear of getting clipped. Of course, none of these olde-tyme railroad practices are very relevant to 21st century rail technology.

Nevertheless, 8 inches is the maximum height of all existing Caltrain platforms. Taller platforms are allowed, but only beyond 7 feet 6 inches (2.3 m) from the track center line; in other words, taller platforms are only allowed if they do not come closer than about 3 feet from the side of a train. A lot of good that does for passengers! Combine G.O. 26 with ADA accessibility requirements, and you get a ghastly regulatory abortion called a "mini high platform" (see figure at right), to facilitate wheel chair boarding using a so-called "bridge plate" manually placed across the yawning moat between the high platform and the train. Mini-high platforms continue to sprout up and down the Caltrain line, most recently in Redwood City and Menlo Park, while elsewhere in the world, humans have discovered level boarding.

Of course, the regulatory rigors of accommodating freight trains are not anywhere on the CHSRA's radar screen, which is why they are planning for level boarding platforms regardless of where Caltrain eventually ends up--one can only hope, higher than eight inches. At stations to be served by both HSR and Caltrain, namely San Francisco, Millbrae, Redwood City or Palo Alto, and San Jose, it is quite possible that we will end up with different, incompatible platform heights with station tracks forever assigned to one or the other type of train. This runs counter to the most basic principles of interoperation, where the flexibility to assign any train to any platform (in a pinch) is paramount.

Moving beyond MOUs, who will bring about amended regulations to ensure that we have a common platform standard for HSR and Caltrain?

Who will make sure this standard allows the off-the-shelf procurement of new trains, without costly redesign? A hint: the most relevant platform heights are 22 inches (550 mm) and 30 inches (760 mm).

Why is Caltrain apparently not vigorously pursuing a waiver of G.O. 26?

High Voltage Electrification

Like platform clearances, overhead electrification of railroads is regulated by the CPUC. General Order 95 specifies the rules governing overhead electric line construction in California. Garden-variety 25 kilovolt overhead electrified railways do not exist in California, and G.O. 95 therefore does not allow them. That's right: 25 kV electrification is currently illegal in California. Caltrain has long-standing plans to electrify the peninsula corridor, and had been pursuing new regulations with the CPUC to cover 25 kV trains. More recently, the approach appears to have shifted towards obtaining a waiver from G.O. 95 instead.

Whatever happens, why is the heavy lifting for high speed rail being left to Caltrain? Moving beyond MOUs, where is the coordinated approach with HSR?

Safety and Train Control

Railroad safety in the United States is regulated by the FRA in a manner that places a premium on crash survival over crash avoidance. That's why we still have the 19th-century practice of train engineers calling signal aspects to their conductor (unless texting on their cell phone), with few if any automated systems to catch human errors. This safety philosophy is well-suited to the cost structure of the heavy freight rail business that dominates our landscape. On the opposite end of the spectrum, high speed rail safety relies almost entirely on avoiding a crash in the first place--not unlike airliners. In Europe, high speed trains zoom through dense fog at nearly 200 mph, with a train control computer watching over the driver's every move. Both philosophies achieve the intended level of safety, but what is supposed to happen when you need to mix both types of traffic on the same corridor, as is planned on the peninsula?

To their great credit, Caltrain is taking the national lead on the issue of mixed traffic regulations, as part of their plan to operate European-style passenger trains that are considered "non-compliant" with existing FRA safety regulations. As of September 2008, Caltrain staff estimated the likelihood of obtaining regulatory relief to be closing on 90 percent. That's very encouraging.

Caltrain's safety concept includes a radio-based positive train control system to be installed on the peninsula when the corridor is electrified, known internally as CBOSS (Communications-Based Overlay Signal System). This raises a host of questions, again moving beyond generic MOUs:

Why is Caltrain specifying CBOSS as a wireless system, excluding an entire segment of the wired train control market?

Is CBOSS an expensive re-invention of the wheel, where existing train control systems such as the Japanese Digital ATC and the European ETCS Level II might plug-and-play?

Why is Caltrain moving ahead with a solicitation this year, fueled by $500k in federal funds earmarked by congresswomen Jackie Speier and Anna Eshoo, for implementation in the next couple of years--before HSR train control requirements are fully defined?

Why should Caltrain be taking the lead on this critical technology issue, when the standard they develop will need to be applied California-wide to the entire HSR system and likely other HSR corridor traffic such as Metrolink, Union Pacific and BNSF?

Doing It Right

Sometimes, doing it right means stopping and charting a new course. One of the fundamental principles of good systems engineering is that you must develop a complete and concise set of design requirements before you dive into the detailed design of station platforms, overhead electrification or complex train control systems. Caltrain does not seem to have fully absorbed the extent to which HSR alters the requirements of nearly every improvement project in their pipeline. Preliminary design activity on all the above items should be slowed and resources re-allocated towards bringing the technical requirements and regulatory framework into better focus. The successful integration of HSR and Caltrain on the peninsula corridor depends on it!