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!
----------------------------------------------------------------------------------------------------------------------------------- K.P.’s absolute “theorem” from early, early childhood that he has seen over and over and over again: Those that CAUSE a problem in the first place will act the most violently if questioned or exposed.
AY YI YI YI... the wrench of the left-handed monkey!
Semper Vaporo
Pkgs.
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.
diningcarA glitch, and there will be others elsewhere, that will be fixed with a "patch" unique to this situation. Happens all the time in other disciplines.
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.
RME 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.
-Don (Random stuff, mostly about trains - what else? http://blerfblog.blogspot.com/)
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)?
Larry Resident Microferroequinologist (at least at my house) Everyone goes home; Safety begins with you My Opinion. Standard Disclaimers Apply. No Expiration Date Come ride the rails with me! There's one thing about humility - the moment you think you've got it, you've lost it...
I believe that one of the three levels is an Industrial track, and another is a branch, neither of which will likely require PYC.
tree68Tehachapi 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)?
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.
Never too old to have a happy childhood!
BaltACDI 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.
oltmanndThey 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.
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. Harrier 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.
I don't know if CP operates trains that are long enough to cross over themselves or not. In the spring of '03, my wife and I were in the area, and I took pictures of a train as it entered and as it exited one of the tunnels--it was not long enough to show the engine at one end and the rear at the other end of the tunnel in one picture..
Johnny
RME diningcar A glitch, and there will be others elsewhere, that will be fixed with a "patch" unique to this situation. Happens all the time in other disciplines. 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.
diningcar A glitch, and there will be others elsewhere, that will be fixed with a "patch" unique to this situation. Happens all the time in other disciplines.
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.
K. P. HarrierTechnically, even with flyovers, a geographic pinpoint location is fouled in a GPS sense. How PTC gets around that would be interesting to know.
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.
I will point out what seems to have been overlooked about the Tehachapi loop that makes it quite different from the other location mentioned. Namely that it is the same specific track. PTC is designed to identify what track each train is travelling on, so those examples where the different tracks are grade separated are irrelevant, the same way they are in traditional track based signal systems.
Nevertheless, an interesting glitch, and probably easily solved. It illustrates why so much care must be taken before a vital system is allowed to go into full service.
John
cx500I will point out what seems to have been overlooked about the Tehachapi loop that makes it quite different from the other location mentioned. Namely that it is the same specific track.
Actually, I did think of that.
What might still be confusing to the system is that these days locomotives run virtually everywhere. Thus a locomotive from "X" may run over a flyover one day, and under it the next (at least figuratively speaking).
Having no idea how the technology works at it's deepest, I don't know how a locomotive would know which line/track it's on - perhaps that comes from the "back office" via realtime streaming. If that's the case, the intersection between the two lines (the point where they cross over) is of little consequence, as it would not show up on the system at all.
And with that considered, the problem with a loop becomes clearer. I'd have to imagine that the approach would be similar, however, regardless of what the GPS says.
Balt's mention of multi-track territories might also be of value, as lineside detection could probably be used to work through the problem.
My problem isn't so much that something like this happened, but that it happened here.
This isn't fly over in west Podunk Iowa, this is tehapchi loop for crying out loud! People model this in their basement better than PTC has.
Permanent Train Colaguation
Modeling the Cleveland and Pittsburgh during the PennCentral era starting on the Cleveland lakefront and ending in Mingo junction
[quote user="ruderunner"]My problem isn't so much that something like this happened, but that it happened here.
Permanent Train Colaguation [/quote]
Having been in the IT side of CSX (the worst 3 years of my career), I can't stress enough how little railroad knowledge or interest there is in employees involved in the programming and systems design aspects of IT. You can hit them with reality and it is immediately discounted because it doesn't fit with the programming beliefs.
They don't know or care about Tehachapi Loop or Fruit Loops and would have difficulty with either.
[quote user="BaltACD"]
ruderunnerMy problem isn't so much that something like this happened, but that it happened here. This isn't fly over in west Podunk Iowa, this is tehapchi loop for crying out loud! People model this in their basement better than PTC has. Permanent Train Colaguation [/quote] Having been in the IT side of CSX (the worst 3 years of my career), I can't stress enough how little railroad knowledge or interest there is in employees involved in the programming and systems design aspects of IT. You can hit them with reality and it is immediately discounted because it doesn't fit with the programming beliefs. They don't know or care about Tehachapi Loop or Fruit Loops and would have difficulty with either.
My personal belief is that IT employees should not exist full time. Contract workers only.
My company has had 4 it guys in 2 years. They don't understand that they need to keep our (basic) system functioning and insist on "upgrading" it.
These upgrades tend to crash the system for 2 days at a time giving it only a 60% availability rate. Yep that's an improvement. Instead of taking an extra 5 seconds to process the search, we now have to wait 2 days so we can find the answer in 30 seconds.
[quote user="ruderunner"]
BaltACD ruderunner My problem isn't so much that something like this happened, but that it happened here. This isn't fly over in west Podunk Iowa, this is tehapchi loop for crying out loud! People model this in their basement better than PTC has. Permanent Train Colaguation [/quote] Having been in the IT side of CSX (the worst 3 years of my career), I can't stress enough how little railroad knowledge or interest there is in employees involved in the programming and systems design aspects of IT. You can hit them with reality and it is immediately discounted because it doesn't fit with the programming beliefs. They don't know or care about Tehachapi Loop or Fruit Loops and would have difficulty with either. My personal belief is that IT employees should not exist full time. Contract workers only. My company has had 4 it guys in 2 years. They don't understand that they need to keep our (basic) system functioning and insist on "upgrading" it. These upgrades tend to crash the system for 2 days at a time giving it only a 60% availability rate. Yep that's an improvement. Instead of taking an extra 5 seconds to process the search, we now have to wait 2 days so we can find the answer in 30 seconds.
ruderunner My problem isn't so much that something like this happened, but that it happened here. This isn't fly over in west Podunk Iowa, this is tehapchi loop for crying out loud! People model this in their basement better than PTC has. Permanent Train Colaguation [/quote] Having been in the IT side of CSX (the worst 3 years of my career), I can't stress enough how little railroad knowledge or interest there is in employees involved in the programming and systems design aspects of IT. You can hit them with reality and it is immediately discounted because it doesn't fit with the programming beliefs. They don't know or care about Tehachapi Loop or Fruit Loops and would have difficulty with either.
That makes it that much worse. Not only do the not know the 'lay of the programatic landscape' that they are getting involved it, they won't be the same contractor the shows up when that programatic area needs further attention.
If you want to punish an IT 'professional', assign them 'maintenance' responsibilities on a legacy application - the crying will rival that of withholding a pacifier from a teething one year old. They feature it they aren't reinventing the wheel their talents are being wasted.
At the time I was in technology, between Jacksonville and Baltimore approximately 1000 people were employed on the 'crash project' of making all concievable paper streams "paperless".
RME (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).
NS is not using GPS to determine which track a train is on. That will come from through the dispatching system and be verified by a human.
GPS is only one part of the location system for PTC. If GPS location is intermittent, such as when in a tunnel or deep cut, then dead reckoning is used. In signalled territory, the track circuits are used for location - that's what all that fixed signal work over the past couple years is all about.
Balt, I like your enclosing "paperless" in quotation marks.
A few years before I retired, I saw that the Stores Stocking Request that was being used when anyone (with authority) used when requesting that Stores stock a new item was woefully inadequate, for it did not have space for all the information that our new system of keeping track of all sorts of things in the plant called for.
I created a new request that had the required categories on it--and it was available on line in the plant (perhaps also in the company; I never heard from headquarters about it).
Paperless? NEVER!
BaltACDHowver, 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.
Apparently some of our remote locomotive operations now have GPS "fences" they are supposed to be in (in addition to transponders in the track). Some issues with that as well. Seems like it owuld be easier and cheaper to just put a damned engineer in the cab, but what do I know. Guess they have all this figured out in some boardroom.
The opinions expressed here represent my own and not those of my employer, any other railroad, company, or person.
Our community is FREE to join. To participate you must either login or register for an account.