RME oltmannd RME 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. Where the train is supposed to be has nothing to do with the safety part of a PTC system ... that is, it shouldn't. The system needs to KNOW what physical track a train is on, whether or not it has some supposed track number (recent Amtrak high-speed collision with MOW equipment?) or even dispatcher 'verification' (NYC West Side accident in 1967?) I'm sure there is some weaseling about lack of local GPS coverage due to restricted constellation or 220 interference. Local beacons would need to be installed (and kept maintained) where that is the case, and of course this increases the cost and complexity, but imho it is pointless to have a "safety" system that is compromised by exceptions known to breed precisely the chances for accident, in precisely the same proportion, as were present before the whole expense of PTC was undertaken...
oltmannd RME 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.
RME
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.
Where the train is supposed to be has nothing to do with the safety part of a PTC system ... that is, it shouldn't. The system needs to KNOW what physical track a train is on, whether or not it has some supposed track number (recent Amtrak high-speed collision with MOW equipment?) or even dispatcher 'verification' (NYC West Side accident in 1967?)
I'm sure there is some weaseling about lack of local GPS coverage due to restricted constellation or 220 interference. Local beacons would need to be installed (and kept maintained) where that is the case, and of course this increases the cost and complexity, but imho it is pointless to have a "safety" system that is compromised by exceptions known to breed precisely the chances for accident, in precisely the same proportion, as were present before the whole expense of PTC was undertaken...
Sure, but it won't. Any more than it will really know what the true train consist and weights are...
-Don (Random stuff, mostly about trains - what else? http://blerfblog.blogspot.com/)
BaltACD Shadow the Cats owner Oh crap that reminds me I have my biannual refresher coming up in Feb on Compliance with DOT regulations. I would rather give birth again without pain meds while having my wisdom teeth extracted than sit thru that class again. Why not hit the trifecta - all three at the same time.
Shadow the Cats owner Oh crap that reminds me I have my biannual refresher coming up in Feb on Compliance with DOT regulations. I would rather give birth again without pain meds while having my wisdom teeth extracted than sit thru that class again.
Why not hit the trifecta - all three at the same time.
Why Balt because after my last child I had my tubes cut tied burned and hubby had the snip done. I deal with over 200 kids at work aka my drivers that think their world is ending if they do not get their way. Sorry I have enough kids.
RMEI'm sure there is some weaseling about lack of local GPS coverage due to restricted constellation or 220 interference. Local beacons would need to be installed (and kept maintained) where that is the case, and of course this increases the cost and complexity, but imho it is pointless to have a "safety" system that is compromised by exceptions known to breed precisely the chances for accident, in precisely the same proportion, as were present before the whole expense of PTC was undertaken...
Tell it to Congress. Present technology has it's limits, always has and always will. The limits may change over time as technologies benefit from further development, but there will always be limits.
Never too old to have a happy childhood!
Shadow the Cats ownerOh crap that reminds me I have my biannual refresher coming up in Feb on Compliance with DOT regulations. I would rather give birth again without pain meds while having my wisdom teeth extracted than sit thru that class again.
BaltACD caldreamer I am writing the PTC code as part of a program for myself and wish I had the actual ptc rules. The little detailed and technical information that you fined is not that much of a help. I worked in the IT field for 45 years and was a programmer, systems analyst and systems engineer for about 15 of them. Yes, I agree that you need experienced system engineers to design the system, systems analysts to analyze and create the data flow and experienced programmers to write the code. Writing this code is real challenge even for me. And when it comes to PTC you need Tech knowledgeable Locomotive Engineers to reign in all the Techies as they take their flight of programatic fancy and get it grounded in the real world of operating trains over the road - Safely within the rules and not set up any traps for the unwary operate into catastrophy. After all the Locomotive Engineers are the END USERS of all this effort.
caldreamer I am writing the PTC code as part of a program for myself and wish I had the actual ptc rules. The little detailed and technical information that you fined is not that much of a help. I worked in the IT field for 45 years and was a programmer, systems analyst and systems engineer for about 15 of them. Yes, I agree that you need experienced system engineers to design the system, systems analysts to analyze and create the data flow and experienced programmers to write the code. Writing this code is real challenge even for me.
And when it comes to PTC you need Tech knowledgeable Locomotive Engineers to reign in all the Techies as they take their flight of programatic fancy and get it grounded in the real world of operating trains over the road - Safely within the rules and not set up any traps for the unwary operate into catastrophy. After all the Locomotive Engineers are the END USERS of all this effort.
Since we seem to be forming sides and pointing fingers at each other, I'm on Balt's side. When I was working, I got fed up with being pressured to alter reality to fit the computer model.
_____________
"A stranger's just a friend you ain't met yet." --- Dave Gardner
caldreamerI am writing the PTC code as part of a program for myself and wish I had the actual ptc rules. The little detailed and technical information that you fined is not that much of a help. I worked in the IT field for 45 years and was a programmer, systems analyst and systems engineer for about 15 of them. Yes, I agree that you need experienced system engineers to design the system, systems analysts to analyze and create the data flow and experienced programmers to write the code. Writing this code is real challenge even for me.
I am writing the PTC code as part of a program for myself and wish I had the actual ptc rules. The little detailed and technical information that you fined is not that much of a help. I worked in the IT field for 45 years and was a programmer, systems analyst and systems engineer for about 15 of them. Yes, I agree that you need experienced system engineers to design the system, systems analysts to analyze and create the data flow and experienced programmers to write the code. Writing this code is real challenge even for me.
ruderunnerMy personal belief is that IT employees should not exist full time. Contract workers only.
ruderunnerMy 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.
There are plenty of mature, U.S. based, underemployed system and network admins out there to run and update your mission critical systems. Partial solution - Kill the H1B visa program Now! </endofrant> Now, back to topic.
Links to my Google Maps ---> Sunset Route overview, SoCal metro, Yuma sub, Gila sub, SR east of Tucson, BNSF Northern Transcon and Southern Transcon *** Why you should support Ukraine! ***
Yes, Balt, I was referring to your post, with your The simplicity of a PTC 'Quick Reference Guide' just when I posted my reply.
Johnny
DeggestySimplicity? Many years ago, there was in Trains, on occasion, a page of photographs with interesting captions. One was of a brakeman by a handbrake who was puzzled by the instruction how to brake; he was asking "What in tarnation is "counterclockwise?"
Many years ago, there was in Trains, on occasion, a page of photographs with interesting captions. One was of a brakeman by a handbrake who was puzzled by the instruction how to brake; he was asking "What in tarnation is "counterclockwise?"
It is simple compared to the 130 page PTC instruction manual I have.
Simplicity?
The simplicity of a PTC 'Quick Reference Guide'
ruderunnerThey don't understand that they need to keep our (basic) system functioning and insist on "upgrading" it.
I wouldn't necessarily blame the IT guys (and gals). The major vendors are a driving force on upgrades. My Chrome web browser will no longer update because I'm still on Vista. I'm happy with Vista, but now I'm several generations behind what the vendors have come up with. I can't watch the Rochelle webcam on Chrome any more because the flash player won't update now, either.
I'm not sure where these people do their research for "upgrades." It seems like every time they come out with a new product, they leave out those tools I find most useful...
I was lucky - when my employer decided to upgrade from W95/98, I somehow got overlooked and didn't have to deal with NT, which was a major PITA.
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...
DeggestyBalt, 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!
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!
I wish I has access to what CSX spent for paper in 1985 and 2015. 1985 was a paper world. 2015 'paperless'. Doubt there is much difference once inflation is accounted for.
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.
It's been fun. But it isn't much fun anymore. Signing off for now.
The opinions expressed here represent my own and not those of my employer, any other railroad, company, or person.t fun any
Balt, I like your enclosing "paperless" in quotation marks.
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.
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).
[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.
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.
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".
[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.
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.
My problem isn't so much that something like this happened, but that it happened here.
Permanent Train Colaguation
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.
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
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.
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).
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.
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.
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. 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.
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..
Our community is FREE to join. To participate you must either login or register for an account.