Positive Train Control, Tehachapi, and the Impossible
UP has been steadily installing Positive Train Control (PTC) mandated by Federal law until now, with a seemingly impossible at the Tehachapi Loop in California.
The PTC system apparently cannot distinguish a grade separation, a track going over itself, and thus stops trains! Interesting dilemma!
AY YI YI YI… the wrench of the left-handed monkey!
A glich, and there will be others elsewhere, that will be fixed with a “patch” unique to this situation. Happens all the time in other diciplines.
Programmers can’t figure this out from first principles, or the wrong railroaders instructed them in what was needed. Simple Z-axis in the GPS will go a ways toward addressing the situation, as will ‘balises’ at strategic locations … hopefully not telling the system simply to ignore ‘collision’ indications. Hopefully proper software-development protocols with modular/object-oriented code will be followed, to simplify what happens when more ‘glitches’ develop.
This is not as bad as the NAJPTC programmers setting up for trains of zero length. That was a demonstration of stupidity.
Not necessarily. I did a lot of “input discussion” with programmers when I worked in the transportation field - we had the occasional need to have “input buckets” for non-events which would affect other calculations.
They should have found this in PTC lab simulations (actual PTC hardware running “fake” trains). I would think the patch would be not to have movement authorities start or end within a few hundred feet of the place the tracks cross.
Tehachapi is far from the only possible instance of one line crossing another (although in this case it’s crossing itself). And a good many of those grade separated crossings are a lot closer in elevation than Tehachapi.
What, pray tell, are they going to do about the triple crossing in Richmond (I think it’s still there)?
I believe that one of the three levels is an Industrial track, and another is a branch, neither of which will likely require PYC.
Not all track segments are required to be protected with PTC. The simplest discription is that segements of through trackage that handle HAZMAT and/or Passengers require PTC. PTC can be implemented on both signalled and unsignalled trackage.
I believe (but don’t know) that the Richmond triple crossing is in ‘yard’ territory and has no requirement for PTC installation.
Roger. I didn’t know one way or the other.
The fact remains that there are any number of similar crossings, and most recently a number of “flyovers” have been reported in Trains, among other sources, which should cause exactly the same problem.
One thing to remember about ‘techies’ - they are not railroaders. They don’t think like railroaders and for the greater part can’t think of the situations that railroaders take for granted.
PTC as it is being installed, is still in ‘test’ so as to find the real world glitches. As of the time of my retirement, CSX had PTC operational on 28 subdivisions in a variety of operational enviornments. Whenever a PTC ‘activation’ happens, a real time investigation of the circumstance takes place to determine if the ‘activation’ is valid and if it isn’t what form of changes have to be incorporated into the system for ‘proper’ activations.
During my career I was involved in installing computer applications at a number of terminals across the system. No matter how ‘well thought out’ our system was as it pertained to a new terminal, each terminal had unique situations that had to have unique programatic solutions developed to properly cover the situation. PTC will be no different.
Chicago has a number of locations where one or both lines of a grade separation will require PTC, Englewood, being the first that comes to mind. North Philadelphia is another, SEPTA-ex-Reaading under Amtrak NEC-ex-PRR. But is not this latter one already operational? And if a fix worked there, cannot it be applied elsewhere?
Englewood will have frequency separation since Metra and NS have different allocations. Amtrak has faced the same issue with multiple flyover locations under ACSES by combining the inputs from the underlying cab signal systems with the radio messages - “disambiguation” in programmer-speak. The same sort of thing can be accomplished by using track circuits. As long as the “crossing sections” are logically separate PTC should “know” that this isn’t a crossing situation. While this doesn’t help “dark” territory", such territory is usually noticeably free of flyovers.
This highlights the sort of problem that PTC doesn’t solve - fouling of track by equipment that shouldn’t be there and doesn’t have an electronic fingerprint - like a backhoe on the wrong track in the Northeast Corridor.
Thanks. So one way the Tahachapi problem can be solved is by supplementary continiued use of track circuits, possibly retained from the existing signal system. I am sure there are other ways.
The discussion has gravitated somewhat away from the ‘loop’ concept, but the flyover situation, such as at Colton, CA is a valid extension of the discussion.
Technically, even with flyovers, a geographic pinpoint location is fouled in a GPS sense. How PTC gets around that would be interesting to know.
Returning to the Tehachapi Loop dilemma, UP has another loop in California, in the northern part of the State, in the Feather River Canyon with Williams Loop. Maybe operating divisions are not communicating with each other, or the Williams Loop area hasn’t received PTC yet so the issue hasn’t come up.
There is a loop somewhere in Canada, but as I recall a large part of that loop is in tunneling, which I would imagine would have its own PTC quirks …. But I don’t think Canada has a PTC law so that loop is somewhat irrelevant to this discussion.
It is real world problems such as, but not limited to, this that makes the outsiders view that PTC is a simple merging of existing technologies into maddening undtertaking that it really is. All the details that the unknowing gloss over as ‘no problem’ are real world problems that must be solved for the systems to become operational and successful.
K.P, the CP&#
Comment from the former ED of the NAJPTC program.
I don’t recall any issue with “0 length trains”, other than the standard problem that all PTC systems face when the braking algorithm must conservatively assume no loco brakes are applied and no car brakes are available since there are no cars, so the predicted stopping distance gets really long. Eventually FRA et al agreed to allow a less conservative assumption when there are less than N cars in a train.
As to the Teachapi
Re PTC stopping a train at a grade separation, somebody obviously entered the track data wrong.
You are forgetting how GPS works, especially HA-NDGPS and its ‘children’. I hope MC and some of the other mavens come in and discuss the practical implementations of the technology (both in terms of present state-of-the-art and logical developments) from their informed perspective.
If you have an adequate constellation of satellites in view, and your time references are good enough, you can determine not only lat/long “location” but also altitude (it’s actually a position in space that can be referred to a level reference like the one erikem mentioned). Even military double precision might not have done this with enough resolution to discriminate flyover vs. main track level, but fortunately we can include ground-based references in the “constellation” that can get local resolution down to very high precision and, with little additional work, accuracy. For instance, just a couple of beacons with stratum 1 clock enablement (let alone independent grandmaster capability with periodic sync for drift) would give you all the Z-axis separation for even primitive PTC software to make the discrimination, even if ‘track over ground’ alone isn’t set up to recognize location on the flyover approach leads or track the ‘swing’ as the PTC receiver diverges at the switch and then starts up the flyover (which is, again, one of the nominal functions that differential GPS is supposed to assure for track-to-track resolution in places like multiple-track mains or passing tracks for yards).
GPS can detect altitude. At the consumer level, one GPS unit I own can be configured to display altitude. The problems that I see with my unit, the altitude can vary by approximately 50 +/- feet. Not the level of precision necessary to differentiate something like Tehachapi Loop. With that being said, I am certain the level of precision being designed into PTC is greater than my consumer grade unit.
Howver, the level of precision in GPS that railroads are using is not sufficient to positively differentiate tracks in multiple track territory. CSX has a number of engines equipped with accelerometers that report ‘rough track’ in real time to the MofW personnel - Instructions to the Track Supervisors is to inspect ALL tracks at the GPS identified coordinates because the individual track the train was operating on cannot be positively identified.