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.

The Root of the Problem, Visualized

All of the engineering design work for HSR on the peninsula is predicated on a future service plan described in Appendix K of the Alternatives Analysis, featuring 10 commuter trains per hour per direction and 8 high-speed trains per hour per direction, with no timetable coordination whatsoever. The service pattern generator can now display this for you graphically, showing where four tracks would be needed to operate this particular service pattern. We already knew the answer: four tracks everywhere along the entire length of the peninsula.

Where Four Tracks Will Be Needed

"Phased Implementation" is really about asking where will four tracks actually be needed? Before this concept was floated, the basic idea was to lay four tracks all the way up the peninsula, a solution that requires little intelligent thought, but gobs of money.

The way to answer this question objectively is to play with timetables. Actually, a sequence of timetables, each of which represents a "Phase." For Phased Implementation, a "Phase" could be defined as follows:

Phase: a coherent set of capital improvements that enable a new timetable that provides better service, by some agreed-upon set of metrics, as compared to the old timetable.

We already described one example of how you might define service metrics for Caltrain, and these could be expanded to measure HSR service quality. The metrics, regardless of how they are defined, need to be timetable-independent, clear, concise, and transparent to the public. Discrete capital improvements, i.e. construction projects, can then be priced out on an individual basis and examined in the context of the new timetables that they enable. The idea is to pick the low hanging fruit first, and to build the improvements that produce the biggest improvement in the service metrics for the least construction cost or community disruption, i.e. the biggest bang for the buck.

The Service Pattern Generator

To exemplify the phased planning process and to make it more accessible to the armchair service planner, we can take the train performance calculations previously presented and fold them into an automatic service pattern generator that generates a graphical representation of a timetable and immediately highlights where additional tracks will be needed on the peninsula corridor.

Try it for yourself: Service Pattern Generator

Rather than work with tables of departure times, this tool specifies intuitive clockface timetables as graphical position-versus-time string diagrams, based on a few basic parameters for each type of train on the peninsula corridor:

• Train type, as described in the train performance calculations, which determines how many seconds it takes a train to travel from one stop to the next;
  
• Speed limit of the track, which can be considerably lower than the train's capability and also determines stop-to-stop times;
  
• Station stopping pattern and dwell times, strongly influenced by whether or not level boarding is provided;
  
• Frequency in trains per hour, or conversely, the clockface interval. For example, 4 trains per hour = 15 minute interval;
• Time offset in minutes from the top of the hour. This offset determines where this train meets other trains in the service pattern, and ultimately determines where you need overtaking tracks;
• Schedule padding, in percent of the overall end-to-end run time. 10% padding is a reasonable value.
  

Using these parameters, the various overlapping service patterns that describe Caltrain locals, Caltrain expresses, and high-speed trains can quickly be specified. While the service pattern generator may initially take a while to grasp, it is worth experimenting with it to develop an intuition for how a blended service plan could actually work.

The key output of the service pattern generator is the yellow highlighting that indicates where trains will catch up and overtake. In these locations, triple or quadruple tracks will be required. The challenge is to develop service patterns that provide good service for both peninsula commuters and long-distance travelers, while minimizing the cost and community disruption that comes with additional tracks.

Professionals do this using much more powerful software that can quantify how resistant these timetables are to cascading delays, but the ultimate results might not be too far off from what this simplified tool produces, when using conservative values for dwell and padding. Far from trying to do the pros' job for them, this exercise empowers the public to understand the trade-offs that must be contended with.

Working Smarter, Not Harder

Using the service pattern generator, we can explore a few examples of how to produce maximum bang for the buck.

Example 1: here's what Caltrain might look like with a mid-line overtake, often mentioned on this blog as the next logical step after (some would even say before!) electrification. Expresses meet locals at Hillsdale to exchange passengers across the same platform. Only one new grade separation is required at 25th Ave. The local holds for three minutes at Hillsdale so that downtown San Mateo can remain with two tracks. This is a typical illustration of cost vs. benefit: the hundreds of millions needed to quadruple-track San Mateo have to be weighed against the two-minute savings for the local. In this particular example, your metrics would tell you that it's not worth it.

Example 2: here's what things might look like with 3 high-speed trains per hour thrown into the mix. We now assume the entire corridor has been upgraded for 100 mph operation, which presumably implies major grade separations and crossing improvements. Introducing HSR requires quadruplication from South San Francisco (well, probably Bayshore) to Burlingame. The bottleneck at San Mateo is allowed to remain with two tracks. Further south, Atherton and Menlo Park are spared while Palo Alto and Mountain View require quadruple tracks. These two new overtake sections illustrate what would be required to provide a reasonable starting level of HSR service via Pacheco. Notice how no enormous civil works are required anywhere in the terminal areas, whether in San Francisco (no expensive tunnels starting at Bayshore) or San Jose (no hulking multi-level station). Transbay to SJ HSR trip time is less than 45 minutes; this can be reduced by increasing the HSR speed limit to 125 mph, but as you'll see if you try it, considerably more construction would be required. Are the few minutes saved worth the extra investment?

Example 3: in the never ending Altamont vs. Pacheco debate, Pacheco proponents often point out that this route is clearly best for Caltrain because it "improves" Caltrain all the way to San Jose. Try this for improvement: here's a service pattern where high-speed trains don't gum up the corridor and head for Altamont from Redwood City. This pattern assumes 4 trains per hour Caltrain local, 4 tph Caltrain express, 4 tph HSR to San Francisco, 4 tph HSR to San Jose via the East Bay, and 4 tph of Dumbarton local commuter rail. 20 trains per hour is a very high level of peninsula train service, probably more than the region will ever need... and look!

• No expensive new SF tunnels starting at Bayshore
  
• All Caltrain service terminates at Transbay
• Two tracks through Burlingame and San Mateo
• Two tracks through PAMPA (Palo Alto Menlo Park Atherton) and all the way south to Santa Clara
  

All this is enabled by only two overtake sections, grade separation of the northern half of the corridor, and punchy 6000-kW Electric Multiple Units (and also, to be fair, a new Dumbarton crossing).

Announcing: the Peninsula Blended Plan Contest

If you like the power of experimenting with service patterns, there's a contest you can enter! Entries may be made in the comments section below by copying and pasting (or better yet, linking) the URL string of your favorite service pattern, with a short paragraph to describe why you think this is the best balance of service, cost, and community impact. Entries will be judged by an impartial panel of armchair experts consisting of Clem and Richard Mlynarik (the brains behind the tool), whose own service patterns will not count for the contest.

The grand prize, a big shiny ASCII trophy known as the Takt Cup, will be awarded in two weeks.

Calling All Service Planners

The recent talk of phased implementation and a "blended" Caltrain + HSR system has some people proposing new service patterns and new timetables. That's a healthy thing: service planning should always drive infrastructure decisions. To ground this discussion in reality, these proposed service patterns must reflect realistic train performance that doesn't require Star Trek warp drives (or, for that matter, four tracks everywhere from San Francisco to San Jose...)

Using a Train Performance Calculator, we can find out how long any given train will take to travel from point A to point B, taking into account grades, rail adhesion, aerodynamic drag, traction and braking curves, line speed limits, etc. The results of such calculations are presented below for four key types of rolling stock on the peninsula rail corridor. With these run times, you've got all the building blocks you need to build your own strings, and from those strings, your own timetable.

The trip times can be downloaded as an Excel spreadsheet (82 kB) or a PDF document (106 kB) with eight separate tables (each in its separate worksheet) corresponding to the scenarios described below. They are reasonably accurate, but perhaps not down to the second.

Caltrain Diesel Train

The prototype for the first set of run times is a standard Caltrain consist, with one F40 locomotive and five gallery cars. The diesel locomotive is rated at 3200 hp, and the entire train weighs 420 metric tons fully loaded with 500 passengers. The train is technically capable of reaching a top speed of 100 mph, although signal system restrictions (planned to be removed) constrain it to 79 mph today.

Note: despite their bullet nose, the Baby Bullet trains have essentially the same performance.

Diesel Multiple Unit (DMU)

The prototype for the following run times is a Siemens Desiro Classic DMU. This DMU is in common use around the world, including here in the United States (although it is not compliant with FRA crash regulations). The train performance specs are based on San Diego's Sprinter, with a four-car consist as shown in the photo. Total power output is 1680 hp total for a train weighing 392,000 lb fully loaded. Top speed is 75 mph; because of this limitation, the run times are valid regardless of the track speed limit.

Electric Multiple Unit (EMU)

The next set of run times is for a Stadler KISS EMU. This six-car double-deck EMU, similar to the types under consideration for Caltrain's electrification project, has a top speed of 125 mph. The spec sheet shows that the train weighs about 325 metric tons fully loaded with 500 passengers, and is rated at 4000 kW (5300 horsepower).

The EMU's secret weapon is the ability to unleash a short-term (few minutes) burst of 6000 kW (over 8000 horsepower), which takes it into the same performance league as a high-speed train. This is handy for performing overtakes on the express tracks without disrupting high-speed traffic--a key capability for a "blended" Caltrain + HSR plan. This trick is not possible with a DMU, which is more akin to a moped entering a freeway. The run times below are for the same train using its 6000 kW short-term rating, to be used sparingly.

High-Speed Train

The final set of run times is for a state-of-the-art high-speed train of the sort that might someday be used in California. It is an 11-car Alstom AGV with a top speed of 220 mph, but used in this case at far lower speeds. The train weighs 404 metric tons and has a very high power output of 9120 kW (over 12,000 hp) as is common for high-speed trains. Generic high-speed train specifications have been compiled by the CHSRA.

If you missed the download link above, here it is again for all the above scenarios: Excel spreadsheet (82 kB) or PDF document (106 kB)

Rules of Thumb

1. These run times are start-to-stop times only, with no intermediate stops, and do not include dwell or padding. Think of them as the fastest possible timing from Point A to Point B without stopping.
   
   
2. Dwell time at stations is not included, and must be added separately. Caltrain dwell times can generally be assumed to be about 45 seconds if level boarding is not provided (i.e. there are steps into the train), or 30 seconds if level boarding is provided. Reduced dwell times can provide enormous savings for frequent-stop commuter trains. High-speed train dwell times should be (per TM-4.2 Phase I Service Plan) 90 seconds at intermediate peninsula stops, and 120 seconds in San Jose.
   
   
3. Padding is not included, and must be added separately. Without padding, a timetable can only be run under perfect conditions. In the real world, stuff happens, and padding ensures that the entire timetable doesn't collapse like a row of dominoes. A good rule of thumb is 20 seconds of padding per stop.
   
   
4. Speed limits ought to be selected carefully. It is unlikely that speed limits will increase where grade crossings are still present. (While this is technically permissible under FRA regulations, state regulations are more restrictive, based on the risk profile of each individual crossing. On the peninsula these crossings typically have a lot of road traffic.)

Building Strings for a Timetable

With the preceding rules of thumb in mind, it becomes a reasonably straightforward exercise to build a "string" that describes the position versus time of any given train, whether it be local, limited, express or long-distance HSR--based on the prevailing speed limit, train type, and stopping pattern. For example, we can construct the timetable for Caltrain 216, departing 4th & King at 7:19 AM, using the following building blocks:

• 4th & King to San Bruno: 691 seconds
• Station dwell at San Bruno + padding: 45 + 20 = 65 seconds
• San Bruno to Burlingame: 314 seconds
• Station dwell at Burlingame + padding = 65 seconds
• Burlingame to San Mateo: 148 seconds
• etc.

By the time you get to San Jose, it all adds up to an 8:25 AM arrival... three minutes early by Caltrain's timetable, but that has some extra generous padding at the end of the run, in order to juice their on-time statistics.

Once you've built a few "master" strings for the basic Caltrain and HSR service patterns that you envision, you can put them on a spreadsheet and slide them around to build the best-possible clockface timetable. When you do this, make sure that no two strings in the same direction of travel ever come within less than about 3 minutes of each other--otherwise, passing tracks will have to be added to allow the strings to touch or cross. This process illustrates how a timetable can tell you where the four-track sections are actually needed.

Bear in mind the limitations of this simplified approach. The most beautiful timetable can fall apart when things don't go according to plan. The pros use expensive software that can figure out how robust a particular timetable will be to the inevitable perturbations, something that factors heavily into service planning. That particular aspect of the problem isn't dealt with here.

Happy timetable building.

The Small Print

The trip times were calculated in Octave using numerical integration of the differential equations of motion. Traction, friction and drag curves are taken from train specification sheets; where not available, these are calculated based on weight on drivers and power (for traction) and the modified Davis equation (for friction and drag). Curve and terminal area speed restrictions are included. The speed limit assumptions include: 35 mph in the Transbay Transit Center; 40 mph out to 4th & King; 65 mph at Bayshore; 70 mph at Sierra Point; 75 mph at San Bruno (assumes new grade separation); 75 mph at Millbrae; 85 mph at Hayward Park; 80 mph at Palo Alto; 70 mph at Lawrence / Bowers; 45 mph in the San Jose approach. All trip times take into account the 0.6 mile discontinuity in the milepost numbering near CP Coast. All trip times assume that the train accelerates and brakes at the maximum service rate, and maintains a margin of 2 mph below the speed limit at all times. Small (few-second) differences in northbound vs. southbound trip times are ignored. Results should be accurate to about ten seconds. Your Mileage May Vary.

Phased Implementation

UPDATE 4/30: A more detailed memo has now been posted for approval by the CHSRA board this Thursday. It describes the first phase, the last phase (full four-track build-out), but nothing in between describing what all these intermediate phases might actually look like.

Original Post: The California High-Speed Rail Authority has now posted their description of what 'phased implementation' means for the peninsula. The Phased Implementation Fact Sheet and Phased Implementation Q&A are the first documents posted to the CHSRA's San Francisco - San Jose document library following an eight-month dry spell. Look for this to become the new buzzword.