zardoz jeffhergert A few days ago, on a PTC equipped engine with the display alternating between "cut out" and "system unavailable", I twice received a penalty brake application from the PTC system. Lots of flashing red on the screen when the penalty braking is in effect. Jeff Gee, with all of that going on, how the heck do you keep your trains in one piece?
jeffhergert A few days ago, on a PTC equipped engine with the display alternating between "cut out" and "system unavailable", I twice received a penalty brake application from the PTC system. Lots of flashing red on the screen when the penalty braking is in effect. Jeff
A few days ago, on a PTC equipped engine with the display alternating between "cut out" and "system unavailable", I twice received a penalty brake application from the PTC system. Lots of flashing red on the screen when the penalty braking is in effect.
Jeff
Gee, with all of that going on, how the heck do you keep your trains in one piece?
I was lucky, my train that day was 90 loaded (agricultural chemicals) covered hoppers. Trains like that, all the same type of cars and load status, usually don't have a problem. It's the very large, slinky manifests that tend to break in two in those situations. That's why we have a 40mph restriction on some of them. To avoid having to go to suppression when the cab signal goes to restricting.
BaltACDAnyone that thinks implementing PTC is as simple as falling off a log is in for a rude awakening.
That sir, is a most egegious understatement.
DeggestyLet Congress know that their predecessor acted without knowledge and another extension may be necessary.
With all the career politicians in Congress, their predecessor is themselves...
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...
BaltACD jeffhergert We are supposed to have PTC turned on by the end of summer. There are people in the field working on the hardware getting it ready. I guess it has been causing the approach-lit signals at times to turn themselves on when there are no trains in the block. A few days ago, on a PTC equipped engine with the display alternating between "cut out" and "system unavailable", I twice received a penalty brake application from the PTC system. Lots of flashing red on the screen when the penalty braking is in effect. Jeff Had PTC operational on two Dark subdivisions for 6 months before I retired. Dispatcher and crews had some initial problems in making Main Track switcing moves - the problems were worked out in short order. Anyone that thinks implementing PTC is as simple as falling off a log is in for a rude awakening.
jeffhergert We are supposed to have PTC turned on by the end of summer. There are people in the field working on the hardware getting it ready. I guess it has been causing the approach-lit signals at times to turn themselves on when there are no trains in the block. A few days ago, on a PTC equipped engine with the display alternating between "cut out" and "system unavailable", I twice received a penalty brake application from the PTC system. Lots of flashing red on the screen when the penalty braking is in effect. Jeff
Had PTC operational on two Dark subdivisions for 6 months before I retired. Dispatcher and crews had some initial problems in making Main Track switcing moves - the problems were worked out in short order.
Anyone that thinks implementing PTC is as simple as falling off a log is in for a rude awakening.
Johnny
jeffhergertWe are supposed to have PTC turned on by the end of summer. There are people in the field working on the hardware getting it ready. I guess it has been causing the approach-lit signals at times to turn themselves on when there are no trains in the block. A few days ago, on a PTC equipped engine with the display alternating between "cut out" and "system unavailable", I twice received a penalty brake application from the PTC system. Lots of flashing red on the screen when the penalty braking is in effect. Jeff
Never too old to have a happy childhood!
We are supposed to have PTC turned on by the end of summer. There are people in the field working on the hardware getting it ready. I guess it has been causing the approach-lit signals at times to turn themselves on when there are no trains in the block. A few days ago, on a PTC equipped engine with the display alternating between "cut out" and "system unavailable", I twice received a penalty brake application from the PTC system. Lots of flashing red on the screen when the penalty braking is in effect.
MikefromGERI admit I don't quite understand what you mean about the CADS system - any signalling system that is worth its money should be positively aware where it has routed trains and which tracks they occupy. Lineside detection and identification of the lead unit and detection when the FRED has passed are not witchcraft IMHO.
The only "thing" that knows where a train is, for certain, is a track circuit. The train dispatching system "knows" that a specific train is in a specific spot by inference. That is, train ABC was here, headed east, and now the next block is occupied, so it must be train ABC. The train tracking function in the dispatch system is not a safety system. It's just informational, that is, it's nice for the dispatcher to know the ID of the train occupying a section of track, but it's not vital for safety. Train tracking in dispatch systems have been known to have bugs that cause them to lose ID's from time to time and the dispatcher has to manually relabel.
The PTC problem comes from the train having to know what track it's on. The dispatching systems haven't been safety systems. Safety is all in the field - note in the back office. So, getting safety critical info from the back office is problematic. So, you either have to install new hardware like transponders in the track and antennae on every lead locomotive, or use some other method. RRs have chose to use human verification of info from non-safety critical systems.
-Don (Random stuff, mostly about trains - what else? http://blerfblog.blogspot.com/)
I suspect CA opens a whole host of acronyms.
We use CAD in the emergency response system, too - as in Computer Aided Dispatch. Depending on the sophistication of the design, such a system can range from simply listing the appropriate response from a table to dynamically recommending proper responses based on known available resources.
F'ristance if Engine 2 is out on a response when a call comes that would normally call for E2's response, the computer can tell the dispatcher to send another unit in it's place.
Normally, the human dispatcher has to "sign off" on that altered response. Once that happens, though, the computer can handle alerting the necessary units, even to the point of using a computer generated voice on the radio.
A far different application of the term than what Balt is speaking of.
Which came first, Computer Aided Design System or Computer Aided Dispatching System?
The use of the same acronym for two entirely different things can be confusing; to me, the context here says that it is an aid for dispatching.
CADS is 'Computer Aided Dispatching System'. There are different CADS systems on each of the Class 1 carriers - The various CADS systems were all installed prior to the PTC mandate and are being updated by their manufacturers in accordance with the PTC standard that have been developed by the carriers and the FRA.
It is critical for PTC to be 'RIGHT' when it begins operation in more than a testing enviornment. Tehacapi is a bug found in testing, the bug will be resolved - that is why territories are implemented sub division by sub division. You can't railroad without geography and geography is different everywhere.
BaltACD PTC coverage affects more than just trains - MofW authorities, Work Zones, Temporary Slow Orders. Interaction with the various carriers CADS systems (which supply the 'back office' information that make the system run. Part of the CADS system is knowing which track trains are being routed to by the signal system). Trains don't dispatch themselves - Train Dispatchers set up routes for each train's operation.
PTC coverage affects more than just trains - MofW authorities, Work Zones, Temporary Slow Orders. Interaction with the various carriers CADS systems (which supply the 'back office' information that make the system run. Part of the CADS system is knowing which track trains are being routed to by the signal system). Trains don't dispatch themselves - Train Dispatchers set up routes for each train's operation.
I understand that. But that doesn't mean high-precision GPS is absolutely indispensable for PTC - it is just a question of how much hardware a railroad is willing to stick on its track. The NEC, for example, could probably implement full PTC without (I don't know what system they are going to use) because much of what they need is already in place. You can safeguard a work zone by slapping down short-range transponders at the ends of the zone that will trigger a speed reduction or a penalty brake application - whatever you need. The same can be done for slow orders, although I concede it's easier just to define the slow order zone by a few mouse clicks on the dispatcher's display and leave it to the trains to know when they are approaching it and do the necessary. Locos equipped with suitable dead-reckoning equipment will have a pretty good idea at which milepost they are - though not necessarily on which track.
I admit I don't quite understand what you mean about the CADS system - any signalling system that is worth its money should be positively aware where it has routed trains and which tracks they occupy. Lineside detection and identification of the lead unit and detection when the FRED has passed are not witchcraft IMHO.
MikefromGERWhy not simply put axle counters at both ends of the critical track and use those to determine track occupancy? Surely there is a way to integrate conventional signalling resources with GPS-based PTC systems, as is done in the ETCS Level 2 systems, although ETCS doesn't use GPS to detect the position of trains, but vehicle-mounted dead-reckoning equipment regularly updated by position beacons (see the Wikipedia article "European Train Control System", section "Levels of ETCS").
Why not simply put axle counters at both ends of the critical track and use those to determine track occupancy? Surely there is a way to integrate conventional signalling resources with GPS-based PTC systems, as is done in the ETCS Level 2 systems, although ETCS doesn't use GPS to detect the position of trains, but vehicle-mounted dead-reckoning equipment regularly updated by position beacons (see the Wikipedia article "European Train Control System", section "Levels of ETCS").
.
oltmannd 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.
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.
To my knowledge no one using the WABTEC system (and except for the NEC that's almost everyone) is using GPS for track differentiation. I sure wonder where some of this "information" comes from?
tree68 I wonder if there will be something like "PTC Lite" that will allow use of a portable package on equipment that doesn't regularly need it. It might also serve an an interim measure until installation of PTC equipment is universal. A shortline with trackage rights on PTC track and several locomotives would be an example, if the rest of their operation didn't require PTC (yet).
I wonder if there will be something like "PTC Lite" that will allow use of a portable package on equipment that doesn't regularly need it.
It might also serve an an interim measure until installation of PTC equipment is universal. A shortline with trackage rights on PTC track and several locomotives would be an example, if the rest of their operation didn't require PTC (yet).
I think there is an exeception for short lines that need to use PTC equipped tracks of another company but otherwise don't need PTC. IIRC, it is for distances of not more than 20 miles. There may be other items included, like needing an absolute block, etc.
Shadow the Cats ownerRME we have the most current GPS civilian level tech in our trucks.
Yes, but what you likely have is GPS for vehicle tracking, perhaps through a service like Comserv (which is what my wife's much smaller company uses). Even when these use something like a SIRFstar chip that can track up to 24 satellites in the constellation, they don't have either the internal temperature precision or clocking to achieve reliable high accuracy, and of course they likely don't have a network of reliable fixed differential beacons (yet).
If you look over on the surveying side, or at some of the potential GIS applications, there is equipment (not cost-effective, of course, for installation on trucks in general commerce) that can resolve well enough that receivers on both ends of a road-grader blade can control it to achieve 'finish' grade automatically in operation.
I had quite a bit of fun a couple of years ago trying to explain to a disbelieving sales "associate" at a company manufacturing miniaturized atomic clocks that I had an application that would potentially require several thousand of them...
BaltACDAfter all the Locomotive Engineers are the END USERS of all this effort.
And the END they are at is the one that's going to run into something that shouldn't be there.
RME oltmannd Sure, but it won't. Any more than it will really know what the true train consist and weights are... Note that I'm not being argumentative to BaltACD, who has both the wisdom and distinctive professional competence to be particularly respected in discussions of how PTC and dispatching are interrelated. One thing that a PTC system "can" (or should be designed to) know is where all trains ARE at all times. If there is a problem with one sensing methodology losing track of equipment (as with the Australians and sand making EMUs 'invisible' at critical times) or providing false indications (as with drift in GPS abruptly causing the system to 'think' a train has crossed over between tracks when it hasn't, or with equipment crossing over when and where it shouldn't, as with the recent MOW train/M8 sideswipe) some intelligent combination to provide redundancy in the systems-design sense can and should be made. If there is uncertainty, do what the rules would call for in a similar situation: hold the train until someone with proper knowledge and authority releases it. The consist and weight issues are different, and more complex. Under most circumstances I think they are likely to be less critical than position information, and they are certainly not things that require continuous update for 'mandated' reasons. I'm sure Sarah or her successor would be interested in an 'automated capability' within PTC to detect if hazmat cars are losing their loads, or if some buffoon has shoehorned 100 tons of trona into cars waybilled at 60 tons, or reliably recognizing cars that have had their brakes released by teenagers to roll downhill into parked switchers. But most of this is not on the same level as determining reliably where trains are when they are at risk of coming into contact, and I think they come into the same category as ECP in providing poor 'bang for the buck' implemented as default, continuous, mandated systems.
oltmannd Sure, but it won't. Any more than it will really know what the true train consist and weights are...
Note that I'm not being argumentative to BaltACD, who has both the wisdom and distinctive professional competence to be particularly respected in discussions of how PTC and dispatching are interrelated.
One thing that a PTC system "can" (or should be designed to) know is where all trains ARE at all times. If there is a problem with one sensing methodology losing track of equipment (as with the Australians and sand making EMUs 'invisible' at critical times) or providing false indications (as with drift in GPS abruptly causing the system to 'think' a train has crossed over between tracks when it hasn't, or with equipment crossing over when and where it shouldn't, as with the recent MOW train/M8 sideswipe) some intelligent combination to provide redundancy in the systems-design sense can and should be made. If there is uncertainty, do what the rules would call for in a similar situation: hold the train until someone with proper knowledge and authority releases it.
The consist and weight issues are different, and more complex. Under most circumstances I think they are likely to be less critical than position information, and they are certainly not things that require continuous update for 'mandated' reasons. I'm sure Sarah or her successor would be interested in an 'automated capability' within PTC to detect if hazmat cars are losing their loads, or if some buffoon has shoehorned 100 tons of trona into cars waybilled at 60 tons, or reliably recognizing cars that have had their brakes released by teenagers to roll downhill into parked switchers.
But most of this is not on the same level as determining reliably where trains are when they are at risk of coming into contact, and I think they come into the same category as ECP in providing poor 'bang for the buck' implemented as default, continuous, mandated systems.
The PTC regs already allow for unequipped trains to mix with equipped ones in certain covered areas. Slow, transfer runs, for example. This seems to be a worse problem than having some sort of postive system for dark territory (in CTC territory, the "which track" problem is pretty well covered by track circuits.
Furthers on Tehachapi Loop
Sources indicate what UP did was activated PTC from the north south to the south switch of the Woodford siding, reinitiating PTC from the new two-track intermediates between CP WALONG and CP MARCEL, in essence, leaving a block on each side of Tunnel 9 at the Loop. PTC is thus in limbo at the Loop until such a time as the powers that be figure out some kind of hocus pocus.
----------------------------------------------------------------------------------------------------------------------------------- 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.
Shadow the Cats ownerRME we have the most current GPS civilian level tech in our trucks. Our margin of Error in loactions is still 20 Meters even when we have 3-4 sats giving signals to the units for the trucks location. That is 66 feet or the length of one of my tractor trailers in error. Then when the location system has a brain fart it will show we have equipment that is in our yard 40-50 miles away at times. Heck we had one driver make his delivery and our Top of the line system still claimed he was in the freaking yard. Why did it never update us on his location our mechanics had forgotten to plug his GPS unit back in after working on the truck. He was only hauling Acid BTW.
Track centers in multiple track territory are normally between 15 & 20 feet - with equipment nominally occupying 10'6" on each track - while the military may have the precision necessary to differentiate tracks - I don't know if that level of precision is available to civilian projects.
RME we have the most current GPS civilian level tech in our trucks. Our margin of Error in loactions is still 20 Meters even when we have 3-4 sats giving signals to the units for the trucks location. That is 66 feet or the length of one of my tractor trailers in error. Then when the location system has a brain fart it will show we have equipment that is in our yard 40-50 miles away at times. Heck we had one driver make his delivery and our Top of the line system still claimed he was in the freaking yard. Why did it never update us on his location our mechanics had forgotten to plug his GPS unit back in after working on the truck. He was only hauling Acid BTW.
oltmanndSure, but it won't. Any more than it will really know what the true train consist and weights are...
BaltACDTell 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.
The thing is that there are two considerations here, both independent of the assumption Congress made up to 2008 that 'piling on the safety mandates' in a single Act didn't involve complexity or contradictions - which of course was sadly mistaken.
The first thing is that even obsolescent GPS technology will give you "enough" discrimination to resolve trains on adjacent tracks. One method is to provide accurate local differential sources (and fast enough lockup in the GPS receiver to include them). It doesn't matter if there is still a few cm variability or jitter - it's a long way between track centers, and (ideally, at least) the receive antenna location net of all sway and tilt, etc. is over the relevant track center (I spec it over the geometric yaw center of the lead truck, but YMMV).
Now if you don't have the differential set up for better than 'ordinary GPS' quality, things are different - ask MC or refer to one of his previous posts for some good explanations of GPS precision and effective state-of-the-art in GPS technology. "Accuracy" of the sort you get from a network of crApple phones, all with different drift due to overheating of the internal components, talking to each other is not usable in a safety system, no matter how 'astoundingly good' it may be most of the time. It NEEDS to be a reliable, or at least dependable, backup to a dispatcher's skill and knowledge, comparable to the automatic part of an ABS giving a reading that is independent of train-order or track-warrant information.
There are also limits to the systems that have been built for "positive" train control, some of which we've discussed in threads here (and many more of which come up in a discussion of proper software-engineering methodology applied to the subject!) One useful thing about 'railroading' (as opposed to much of the autnomous-vehicle field) is that there is little downside to "failing safe" by bringing trains to controlled stops and then using a properly safe manual procedure afterward; this might get irritating if some common-mode problem like 'diamond snow' or contaminated ballast started causing false-positives, but predicting those is part of a good design process and coping with the inevitable ones that constitute 'contact with the enemy' is another part of it.
What we see, in Congress and out of it, is that much of the coordination of the "PTC mandate" is not as designed as it should be, and that no small part of that is because the scope of the initial requirements was not made either knowingly or well. I do remain confident that PTC functionality as covered by the 'mandate' is technologically 'reasonably achievable' (although perhaps not with some of the very expensive systems and approaches that have been rolled out so far!) and that control supersets may make much of the existing stuff actually work for what is intended. (Hopefully without too much more consternation like the various things leading up to the Amtrak 188 accident!)
Shadow the Cats ownerOh crap that reminds me I have my biannual refresher coming up in Feb on Compliance with DOT regulations.
Ah, yes... Rules Class.
Our community is FREE to join. To participate you must either login or register for an account.