Is that a question, or an opinion? If it's an opinion, then I can not help you.
RWM
petitnjWhat is their problem? NTSB just nailed them to the wall for having multiple signalling systems. It that not enough of a warning? Or is the multimillions of law suits that follow cause them to make things consistent. This is not a hard problem. Upgrade all the signal systems so that yellow over red means the same in every system.
One answer: cost. It would take billions to standardize everything. Billions that an be better spent (IMO) elsewhere. On all my territory yellow over red means approach (unless its a dwarf, then its a slow approach). If I ran somewhere where it meant different, then I guess I'd have to learn it. That's the definition of being qualified.
The opinions expressed here represent my own and not those of my employer, any other railroad, company, or person.
This is about the NTSB findings on the wreck of the Pere Marquette on the south side of Chicago a couple of years ago (see the April 1 "Newswire"). The recommendations were for positive train control and uniform signal rules.
We debated signal uniformity back when the accident happened--Positive Train Control requirements have since come about, and PTC probably would make the confusion meaningless, if nothing else. Or perhaps, since PTC has to be a standardized system, it may require remaining signals (and their rules) to become more standardized.
BTW, I'm kind of smug about being the first person in that earlier thread to come up with what turned out to be the actual cause of this wreck. Guess I'm in the wrong side of business!
But I agree with Zug--in the here and now, you have to know all of your signal systems to be truly qualified on a territory,
Carl
Railroader Emeritus (practiced railroading for 46 years--and in 2010 I finally got it right!)
CAACSCOCOM--I don't want to behave improperly, so I just won't behave at all. (SM)
Even traffic signals aren't really standardized - I can think of several ways that left turns are handled, and that can vary even within one municipality. Ever sit an an unfamiliar intersection, wondering if/when the light was going to change in your favor?
The basics of railroad signalling are there, and are actually fairly consistent across the country, from what I've seen. Yes, there are differences. Many are location specific, so making them consistent with every place else will require an extensive survey of the entire rail system to see if there is anywhere else like them so the aspects can be made the same. That might not be worth the cost.
It does come down to money - new electronics, etc. It also comes down to whose system becomes the standard. In simplest terms (and we all know it won't be simple), with seven class ones, six will be learning some new signal aspects.
In the meantime, as others have said, you have to know your territory.
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...
The NTSB's charge is to describe what it would take for perfect safety. How it is paid for, or whether there are more effective means of spending the same amount of money to obtain even more safety, is not their charge. Just because the NTSB recommends something doesn't mean it is cost-effective, except for fanatics who live in alternative realities where money costs nothing.
PTC renders it all moot anyway. Alas, for the small minority of railfans who believe that signal aspects should be according to their ideas of what is perfect, the signal aspects will not change, at first roll-out of PTC. Eventually all the signals will go away, and with it the aspects, as PTC renders them superfluous, but I expect that 50 years from now there will still be fanatics arguing over which signal aspect system was the "correct" signal aspect system, just as they still argue over which steam engine was the "best" 50 years after the last of them was melted into rebar.
I am under the impression that American railroads are private enterprise. They, not the US Government,control their respective right of ways including signaling. I thought that all crews had to understand the rulebook.I thought that dispachers were company and not federal employees
In Britain,even after nationalization,there was no standardized signaling. The Great Western used lower quadrant semaphores and seachlight signals,not usually seen on the other three companies that became British Railways.GWR engines also had right hand drive,unique to the GWR.The LMS LNER and Southern all used upper quadrant semaphores and had left hand drive. In 1956 there was a serious accident with fatalities when the crew missed a restrictive signal.The engine assigned to the train was a Britannia class 4-6-2 with left hand drive. The track was ex-GWR and so was the crew.The train's driver(engineer) told investigators that the accident would not have happened if they would have been assigned a Castle class 4-6-0, a GWR engine.It was considered a pretty lame excuse. There were many times that crews had to operate a locomotive where seeing signals would be a problem. Even before World War II,the GWR had trackage rights over other lines in which they used their own locomotives.Doesn't it get back to trainning and the rulebook !
Even with the lack of a single standard system, I would have to say that the accidents caused by mis-interpretation do to a lack of knowing the meaning of the signal are extremely rare. I'd venture a guess that simply misreading a signal happens more frequently. That is, for example, the engineer faces a yellow aspect and in his mind decides it is a less restrictive flashing yellow. The single standard system doesn't solve that problem.
"We have met the enemy and he is us." Pogo Possum "We have met the anemone... and he is Russ." Bucky Katt "Prediction is very difficult, especially if it's about the future." Niels Bohr, Nobel laureate in physics
Interesting that you mention flashing signals. Everywhere I know of, with one exception, flashing is "better" than not flashing. The theory is that if the flashing circuit quits, then you either get the more restrictive steady indication or you get a dark signal - which is the same as the most restrictive signal that could be displayed.
The one exception is one of the newest aspects in NA RRing. Amtrak has a "flashing green" which is used for diverging moves on their high speed Xovers. I suspect it was cheaper to come up with a "vital" flashing circuit for a few locations, than any other possible solution.
Some roads use signals to indicate diverging or normal routes thru switches (clear vs. diverging clear) and some use signals to also indicate the permissible speed (clear vs medium clear (30 mph) for a #15 or limited clear (40 or 45 mph) for a #20) and some use signalling to control civil speeds (curves, etc.) It would seem to me that creating a national standard around these would be difficult. You either have to just do the lowest common denominator, leaving everything else wide open (e.g. red over green would be approach diverging with no speed implications. RR #1 would use timetable to specify speed. RR#2 could use red over green to mean 30 mph and red over flashing green to mean 40 mph.) or you tie down everything meaning red over green means 30 mph regadles of turnout geometry. If RR#2 wants 40 mph, they have to upgrade to display red over flashing green. It also would mean that every engr. and conductor would have to be qualified on every signal indication everywhere. A BNSF crew out of Alliance NE would have to know that flashing green means 80 mph through the crossover - even if the only place it's displayed is 1500 miles away on the NEC.
-Don (Random stuff, mostly about trains - what else? http://blerfblog.blogspot.com/)
I asked about this some time ago on this forum and I'm surpised that this thread didn't meet with the same end that mine did. I got a scathing post that instructed me to shut up because signal systems have to be different for reasons that he said were so complex that I could not possibly understand.
PTC is basically everyone starting from scratch, so there is not a variety of systems needing to be standardized. As has been pointed out, signals vary from railroad to railroad (and within railroads). Which one do you pick as best? Who gets the economic advantage in already having that system so they don't need to change while all the others do? Which signal company wins the lottery and puts all the others out of business because they make the winning system?
petitnjAnd the traffic lights and signs in the U.S. are standardized according to the U. S. Dept of Transportation Federal Highway Administration, Manual on Uniform Traffic Control Devices.
The signals are standardized - the applications not so much. This is best illustrated in the variety of left turn set-ups you can find, often in the same city. This is roughly analagous to the specialized signal aspects found at interlockings.
How many years did it take for "right turn on red" to make it across the country?
But you are right - on the highway Red means stop, Green means go. Amber does take on some interesting interpretations, though, ranging from "proceed with caution" to "hurry up before the light turns."
And the signals on the railroads mean the same thing in a large percentage of the cases. The devil is in the details.
For those of us who like to look at the actual NTSB documents ("source" data), below are the links to the available documents and my few comments. The NTSB's final report (many pages) hasn't been finalized yet, so that's why it's not included.
The most interesting aspect of this to me is that one of he FRA regulations actually requires essentially that for railroad signals, Red = Stop, Green = Proceed, and Yellow (or Lunar) = Stop May Be Required. Aside from providing some sense of rationality to the system (and furnishing hope that someday I'll understand it better), since the Amtrak engineer was looking at a Red over Yellow I have to wonder what he was expecting to happen - what part of "might have to stop" did he not understand ? More importantly, as some of the comments above state, this is already is a standard or uniform system for signals !
The actual text of the regulation is also below, from:
http://edocket.access.gpo.gov/cfr_2008/octqtr/pdf/49cfr236.23.pdf
None of this is very difficult reading - I recommend it.
- Paul North.
--------------------------------------------------------------------------------------------------
§ 236.23 Aspects and indications.
(d) The fundamental indications of signal aspects shall conform to the following: (1) A red light, a series of horizontal lights or a semaphore blade in a horizontal position shall be used to indicate stop.
(d) The fundamental indications of signal aspects shall conform to the following:
(1) A red light, a series of horizontal lights or a semaphore blade in a horizontal position shall be used to indicate stop.
(2) A yellow light, a lunar light, or a series of lights or a semaphore blade in the upper or lower quadrant at an angle of approximately 45 degrees to the vertical, shall be used to indicate that speed is to be restricted and stop may be required.
(3) A green light, a series of vertical lights, or a semaphore blade in a vertical position in the upper quadrant or 60
NTSB Board Meetings & Press Conferences:
http://www.ntsb.gov/Events/Boardmeeting.htm - for/ on March 31, 2009
NTSB Press Release (2 pages): http://www.ntsb.gov/Pressrel/2009/090331.html
FOR IMMEDIATE RELEASE: March 31, 2009 SB-09-12
NTSB DETERMINED ENGINEER'S INACCURATE INTERPRETATION OF SIGNAL LED TO CAUSE OF AN AMTRAK ACCIDENT IN CHICAGO
NTSB Abstract / Synopsis (3 pages):
http://www.ntsb.gov/Publictn/2009/RAR0901.html
NATIONAL TRANSPORTATION SAFETY BOARDPublic Meeting of March 31, 2009(Information subject to editing)
Railroad Accident ReportCollision of Amtrak Pssenger Train 371 and Norfolk Southern Railway Freight Train 23M near Chicago, IllinoisNovember 30, 2007NTSB/RAR-09/01
NTSB Board Meeting Presentations:
http://www.ntsb.gov/Events/2009/Chicago-IL/presentations.htm
Although these are the PDF versions, PPT ("PowerPoinT") is also available:
1.) Investigator In Chief (IIC) Presentation (877 KB in size, 25 pages):
http://www.ntsb.gov/Events/2009/Chicago-IL/Chicago_3-31-09_IIC.pdf
The side view photo of the loco mounted up on the container car below on Page 2 of 25 is very dramatic.
Page 12 of 25: Engineer Called the Signal
•
Page 23 of 25: Different Signal Indications
[ Red 0 over Yellow 0 displayed in both graphics]
• Amtrak Terminal - Slow Approach [not exceeding 30 MPH - PDN]
• Stop at the next signal
• Expect a clear track
Conclusions:
(Page 18 of 25)
The engineer misinterpreted and miscalled the signal at Englewood which resulted in the operation of the Amtrak train at a speed greater than authorized ,and when challenged by the relief engineer, the engineer failed to slow or stop the train while he and the relief engineer discussed their differences in understanding the signal displayed at Englewood.
(Page 19 of 25)
The relief engineer failed to communicate effectively and in a timely manner to the engineer that he had miscalled the restricting signal at Englewood interlocking and failed to then take action herself to stop the train after the engineer did not slow or stop the train when challenged.
(Page 20 of 25)
Multiple Signal Systems
(Page 21 of 25)
- Red light must indicate Stop - Green light must indicate Proceed - Yellow light or lunar light must indicate Restricted and Stop May Be Required
- Red light must indicate Stop
- Green light must indicate Proceed
- Yellow light or lunar light must indicate Restricted and Stop May Be Required
(Page 22 of 25)
Adjoining Railroads
(Page 24 of 25)
The lack of uniform meanings of signal aspects can lead to misinterpetation, as demonstrated by this accident.
2.) Human Performance and Emergency Response Presentation (284 KB in size, 6 pages):
http://www.ntsb.gov/Events/2009/Chicago-IL/Chicago_3-31_09_Performance.pdf
Note that the "Accident Engineer's Exam Results" (Page 3 of 6) states and indicates that he initially failed two signals tests (Amtrak and NORAC*) on his 1st attempt, passed NORAC but failed Amtrak on his 2nd attempt, and then passed Amtrak on his 3rd attempt.
* Misidentified Restricting as a Slow Approach
Note that this is the same mistake as was made in the collision !
3.) Survival Factors Presentation (1.63 MB in size, 10 pages)
http://www.ntsb.gov/Events/2009/Chicago-IL/Chicago_3-31_09_survival.pdf
The Crew Extrication photos on Pages 4 (crew seats), 5 (loco from below), and 7 (loco access points, from above) of 10 are pretty dramatic.
Do we have TORT LAWYERS or their SURROGATES using this site, and if so what are they seeking???
If not then those who continue to press on with this question (which has been responded to in detail) should clearly identify their motivations.
Signal systems...even when implemented on the now Fallen Flag carriers were installed over time...the time required to come up with both the traffic to require signaling an the funds to be able to install it. No Class I Carrier ever went from being non-signaled to totally signaled in one fell swoop at one time with a single technology. As time and technology march on from innovation to innovation signaling technology also moves on from innovation to innovation. As each new segment of signaling was installed, the latest 'proven' technology was installed in the new segment. Even if original segment 1 and newly installed segment 99 display the same physical signal aspects....the technology underlying those aspect is totally different. The foregoing presumes that the management of the signal system remains constant.
Consistent management is something that never occurs in large organizations. People retire, people die, people get promoted, people get fired, people leave for other companies and the hallmark of management is, like dogs, they have to leave their marks on their territory. Even if Management A had achieved PERFECTION, Management B has to change it. Now if you view the Fallen Flag carriers from the approximate time electrical signalling was begun to being installed in the approximation of 1900, and factor in that senior Signalling Management changed approximately every 7 to 10 years or so on each of the Fallen Flag carriers, factor in the changing of technology with multiple signal equipment manufacturers over these times, multiplied by the number of Fallen Flag carriers that now make up the current Class I carriers you will begin to see the the complexity of the installed signal infrastructure that currently exists in the industry.
Even if unlimited funds were available to finance total standardization of all signal systems in the industry...the manufacturing capacity and installation manpower to implement and TEST the implementation would require at least a decade to accomplish...during which time technological improvement will occur and will be implemented, thus either breaking the standardization or not be implemented thus leaving efficiency and economy behind.
Never too old to have a happy childhood!
petitnj This is how our system works: 1) Free enterprise resists change 2) Government steps in to standardize things 3) Free enterprise resists further until they are sued or go out of business.
I'm not sure I can agree with your line of thinking here. Can you provide a couple examples where this has happened in the past?
You seem to be jumping to the conclusion that non-standardized signals are the root of the problem. The industry may believe the root of the problem is operators not following the signals. In your scenario, after the government forces the *free enterprise* railroads to fix what the govenment sees as the problem, the problems will still occur. After that, who do you sue, and what will the government standardize then?
Thanks to Chris / CopCarSS for my avatar.
petitnj This is how our system works: 1) Free enterprise resists change 2) Government steps in to standardize things 3) Free enterprise resists further until they are sued or go out of business. And the traffic lights and signs in the U.S. are standardized according to the U. S. Dept of Transportation Federal Highway Administration, Manual on Uniform Traffic Control Devices. (http://mutcd.fhwa.dot.gov/)
This is how our system works: 1) Free enterprise resists change 2) Government steps in to standardize things 3) Free enterprise resists further until they are sued or go out of business. And the traffic lights and signs in the U.S. are standardized according to the U. S. Dept of Transportation Federal Highway Administration, Manual on Uniform Traffic Control Devices. (http://mutcd.fhwa.dot.gov/)
It's obvious that the historical record, facts, reason and logic mean nothing to this poster.
Does he even know about "In the Matter of Container Service", the "Big John" struggle, the fight with the government to allow unit trains, or the countless other attempts by government regulators to prevent change for the better in railroading? If he knew, would he even care? I really doubt that he would.
Since about 1903, the government has consistantly blocked, prevented and stymied progress in US railroading. But that fact doesn't fit the poster's political ideology. So we get this rant from him.
No way does this guy understand the signal system, but he is giving his opinion just the same. I hope he can understand this. I am a engineer who is qualified over 350 miles of trackage and 7 differant railroads, and the signal system they use. It is standardized in that red means stop green means go and yellow means you may stop, not hard to understand, I have seen a few slow appraoch signals in my time And to tell you the truth i have never been diverted or ran thru a yard with a slow aproach signal. If the man did not understand the signal he should have called the dispatcher and asked.
CShaveRR This is about the NTSB findings on the wreck of the Pere Marquette on the south side of Chicago a couple of years ago (see the April 1 "Newswire"). The recommendations were for positive train control and uniform signal rules. We debated signal uniformity back when the accident happened--Positive Train Control requirements have since come about, and PTC probably would make the confusion meaningless, if nothing else. Or perhaps, since PTC has to be a standardized system, it may require remaining signals (and their rules) to become more standardized. BTW, I'm kind of smug about being the first person in that earlier thread to come up with what turned out to be the actual cause of this wreck. Guess I'm in the wrong side of business! But I agree with Zug--in the here and now, you have to know all of your signal systems to be truly qualified on a territory,
Just curious about some of the background facts here. I apologize in advance for displaying my ignorance of this territory - and no, I'm not a tort lawyer, just trying to understand this situation better and assess for myself whether the supposed "non-standardization" of signals really exists and is what needs to fixed, or more attention paid to locomotive engineer training, qualifications, testing, or something else, etc.:
It's Amtrak's line from Detroit to Chicago, correct ? Which was the predecessor RR ?
What kind of signals did it have back in the day ?
What percentage of the Pere Marquette's run is on Amtrak ? On NS ? Any other RR ?
Where's the junction from Amtrak to NS ? Is that also where the signal systems/ aspect "conventions" change ?
Is it obvious that the train is changing from Amtrak and its signals to NS and its signals, wherever that occurs ?
Thanks in advance for any answers and insights, or any other information that I didn't think to ask.
No, Paul, this is NS' line, not Amtrak's. Amtrak owns its own line only between Kalamazoo and Porter, Indiana, and the Pere Marquette route merely intersects with it at Porter. Porter is also where it changes from CSX to NS rails on the way to Chicago.
Back in the day, there would have been PRR position-light signals at this spot, if the track layout was the same (can't state that one positively). There are still some PRR-style signals east of there under which this train would have traveled.
The Pere Marquette runs over CSX from Grand Rapids to Porter, former NYC from Porter to somewhere in Whiting, former PRR from that point the rest of the way in to Union Station. Perhaps the stretch between the 21st Street lift bridge and the station is owned by Amtrak. Signals may not change there, but the rulebook does. The train in question had been operating under NS (NORAC?) rules for 30 miles or more when the collision happened.
I'm not that "up" on the rules of various eastern railroads at this point, so I'm not sure how similar or different CSX's Restricting signals may be from NS'. There would be a change in signal definitions when the train crossed the bridge going into Union Station, since Amtrak operates with GCOR here. Signal styles would change at Porter, and again where the train leaves NYC for ex-PRR trackage. Obviously, some of the old PRR position-light signals have been replaced; CSX is in the process of replacing the old searchlight signals with color-light (don't think it affects aspects, though).
Hope this helps, Paul--I have some more specific information available, but have to go to work soon.
Paul (and others):I am not a railroader and not a lawyer, but observe portions of the line from Porter into Chicago somewhat during my daily travels. Carl has it pretty well pegged as far as ownership and operations.
There are PRR type signals still in operation on a portion of the line, primarly from Whiting into Chicago. I cannot say what type of signal it was, having not seen it. The engineer should have had a copy of the CORA Operating Guide. It does show in both PRR type signals and other types that red/yellow is "restricting".
I have not read the STB ruling, but the summary that concerns me is another engineer was in the locomotive and apparently did not assume control of the situation.
ed
tree68 Amber does take on some interesting interpretations, though, ranging from "proceed with caution" to "hurry up before the light turns." And the signals on the railroads mean the same thing in a large percentage of the cases.
Amber does take on some interesting interpretations, though, ranging from "proceed with caution" to "hurry up before the light turns."
And the signals on the railroads mean the same thing in a large percentage of the cases.
On a train, how does one "hurry up before the light turns"?
zardoz On a train, how does one "hurry up before the light turns"?
Hmmm. Although it does appear that in the incident in question.....
Too, the qualifier after the highlighted portion does take that into account...
I don't see how spending a pile of money in one fell swoop, is necessarily going solve the problem where maybe the problem is that someone is not familiar enough of the territory and also perhaps of a case of not reading the small booklet/mission guide for the conductor as I call it that comes with the waybill. Don't know what it is called but I am looking at a CN one; TGBO maybe? Also, if you have doubts on how to proceed to or through a signal, doesn't it make sense to coordinate further movements through the dispatcher or yard master depending on where you are?
Spending a whole bunch of money doesn't always mean or often mean safer conditions. Better research and communication is often just as good as a few billion dollars.
Carl & ed -
OK, thanks for the replies & additional info. You've pretty well answered my biggest question - from the NTSB diagram, the Amtrak train was crossed-over from Track 1 to Track 2 just before the Englewood interlocking (METRA crossing at grade). There are places here in the Northeast Corridor where a seemingly simple move like that will change the train from Amtrak to ConRail or SEPTA (or NJT or MN, or further North to maybe ConnDOT or MBTA - don't know that end real well, though). That would be a trap for the unwary - though the engineer should have been "wary" anyway - and I was wondering if the setup there was like that at all. Apparently, it isn't - not by a good 30 miles !
I need to think about and digest it all a little more - there may be a few other good points waiting in the wings, but I too have that G-T-W thing to "work around" now. Thanks again, fellas.
A quick point on PTC:
99% of the U.S. will be one of two systems. The "Class 1" universe will all be on a Wabtec platform, which is locomotive-based, peer-to-peer with wayside interface units. UP is proceeding on a "vital" pathway where the PTC will be its own Method of Operation whereas BNSF is proceeding on a "non-vital" pathway with the PTC being an overlay on existing Methods of Operation such as CTC and TWC. NS appears so far to be leaning toward the vital path, CSX hasn't announced, and CN, CPR and KCS are not yet to that level of analysis. The Northeast Corridor universe will all be on the ACSES platform, which is a development of existing cab-signal systems. A few railroads which do not touch either of those universes can do something else, for example, the Alaska Railroad is well along on a US&S wayside-based platform. Some of the commuter railways are stating they would prefer an evolved intermittant cab-signal system such as what GETS has provided for TriMet on the new Beaverton-Wilsonville, Oregon, commuter line. But if they touch a Class 1, that probably won't fly unless they want to dual-equip.
Estimated costs for PTC have doubled in the last year, and then some; I would not be surprised to see the eventual cost in excess of $15 billion.
Many people do not grasp that train-control systems are supposed to deliver efficiency as well as safety. It doesn't do much good to make the system so safe that the efficiency results in bankruptcy of the railways, unless, that happens to be your goal. The Class Is are determined to extract efficiency value from their multibillion dollar investment in PTC. That is going to be an interesting challenge. I haven't decided yet whether I'm having fun yet, though.
A good point - the role of the relief engineer, who hasn't been mentioned much here - has been brought up by Andy. Here are some of my thoughts on that:
1.) The situation is that the regular engineer had been on duty a good while, so he may well have been fatigued - the train had been delayed en route, and that's why Amtrak prudently called a relief crew. The relief engineer offered to take over for him, but he refused. We now know that it had taken him 3 attempts to successfully pass both the NORAC and Amtrak signals exams. Then he's got some girl trying to tell him he's not reading the signals right ?!? So, is anybody else wondering if his ego / machismo was maybe playing an unspoken role here ?
2.) "Dumping the air" on him would have been an emotionally tough thing to do, in any event, with the "brotherhood" railroad culture - she'd likely be marked as the railroad equivalent of a "snitch" or "rat" for the rest of her career. So that's probably why they were arguing about it - "discussing" it per the NTSB report - for the 70 seconds until the impact. Meanwhile - as Andy notes above - the engineer had let the train get up to 40 MPH, when even the signal indication he mistakenly thought he had limited him to 30, so she'd have been justified in pulling the air on him from that alone.
3.) "The rules are written in someone''s blood" has been noted here by others here many times before, and so it is again. The good thing that hopefully comes out of this is a real-life example for all conductors and engineers in training to hear about and realize that the day may well come when they're in that gut-wrenching position and have about 2 seconds to make the decision and act and what are you going to do ? and what if you're wrong ? but what if you're right and prevent the wreck that seems like its going to happen - but am I really sure I'm right ? and is it safer to dump the air and risk passengers being hurt over nothing, or to let this train keep moving and maybe nothing bad will happen anyway, and so on. I can see a good instructor doing some role-playing with this - "You're the relief engineer now - tell us how you'd handle it", and then discuss it in the class, and so on. Certainly anyone who takes the job seriously will then understand the obligation of the other person in the cab.
4.) The specific rule violation by the relief engineer was "In case of doubt, the safe course must be taken." Well, clearly she was in doubt - she said something, and was still debating it - but she didn't take the safe course of stopping the train.
5.) We might ask if her hesitation in dumping the air was based on fear or uncertainty about what the other engineer's story would then be, and what discipline might be imposed if she turned out to be wrong anyway. I don't know what the prevailing attitude is about that on the railroads, but - sticking my neck out here - if I were in charge I'd pretty much give the person who pulled the air the benefit of the doubt, unless he/she had a pattern of doing such things that demonstrated they didn't understand the rules. [EDIT- add/ insert:] I think'd I rather have to pay the claims (and tort lawyers) for some cuts and bruises and broken bones of passengers from a few too-fast stops, than for the costs of a large scale wreck such as this one - or God forbid, another Chatsworth. [end EDIT] Maybe the one in the wrong gets some time off without pay, but I wouldn't fire anyone for that - at least not the first or second time. But for sure they'd have an all-expense paid trip to the next signals class and exam, and not be allowed out on the road again unaccompanied until they passed that exam.
6.) In the "standardize the signals" debate, someone above - I think it was BaltACD and/or oltmannd, naturally enough - made the point that achieving uniformity in the signal systems is an expensive goal that would take a long time - like 10 years ? - to achieve, at great expense, and even at that it's either a moving target that's always changing and hence out of reach to actually complete, or else you have to freeze the technology at some point in time at the "lowest common denominator" level, and is that really what we want, etc. All of those are excellent points, and have to be respected because they're just reality.
However, I'll suggest breaking that down a little bit between:
A.) Making more uniform just the Aspects that are displayed, their Names, and Indications; as distinguished from -
B.) Standardizing the signal systems and circuits themselves, that are in the "background" so to speak, and not visible to the train crews. This is all the province of the signal engineers only, and that's where the serious money would be spent if this had to happen.
The train crews shouldn't care less whether the signal that is displayed is generated by relays, solid state circuits, computers, dispatchers, or trained monkeys* - "Just do what it indicates". As long as those indications are reasonably uniform, that should eliminate the worst of this problem.
[*- No implication intended with the juxtaposition between those last 2 - seriously !]
Behind the scenes, doing that should not commit or force the signals guys to spending a lot of money to upgrade all the circuits and widgets that produce the signals. If they're working fine, no need to change them wholesale and throw them out - perhaps just remove or change the 1 or 2 indications that are "out of step" with everyone else. Yes, I know that it some cases that may be like "splitting the baby" - it's all 1 integrated system, and you can't do that without breaking it open and wrecking the whole thing, etc. OK, then maybe those few systems need to be replaced entirely, or the troublesome function deleted or negated by wiring it to a bulb that doesn't show, or some "workaround" like that - I don't know. There are members here who are far more expert than I (essentially zero qualifications) in such matters, so I'm prepared to be told that in detail and at length - so be it. But perhaps those same people could also tell us if it might work in some instances, or not, or what else could be done short of replacing the entire system, for the reasons that have been mentioned above.
7.) Then again, as has been mentioned, PTC may make the whole thing moot in 5 years. Or not. Time will tell.
Well, I've got to GBTWN (Get Back To Work Now). Let's see what the responses are.
Paul_D_North_Jr However, I'll suggest breaking that down a little bit between: A.) Making more uniform just the Aspects that are displayed, their Names, and Indications; as distinguished from - B.) Standardizing the signal systems and circuits themselves, that are in the "background" so to speak, and not visible to the train crews. This is all the province of the signal engineers only, and that's where the serious money would be spent if this had to happen.
For about $1 billion or so, it would probably be feasible to degrade all the aspecfs nationwide to a lowest-common denominator, and for another $1 billion or so, replace the worst-case scenario installations with new equipment, so that the LCD wasn't rock-bottom low. If anyone wants to claim that it's possible to "write a couple new lines of software" or "move some wires around" in an instrument house, I invite him to put his money where is mouth is and bid the work.
First, the NTSB always finds something wrong. That is what they do. And the don't have any responisiiblity for finding solutions that work, let alone paying for them. I had one dealing with the NTSB years ago. I also knew two individuals who worked for the NTSB. On the basis of that experience and those associations, as well as reading a lot of their reports, I cannot respect either the agency or its people.
Second, most of us (all of us?) hate accepting responsibility for our mistakes. This is especially true if there could be severe consequences. I have read the ICC train accident reports that are/were on line. It is interesting that in the second decade of the 20th century train crew members accepted responsiibility for mistakes. Starting in the 20s they stopped and started blaming the railroad.
Third, often railroaders (and non-railroaders), and most especially, their attorneys, will use any little deficiency on the part of the railroad as an excuse to avoid responisibility -- and/or -- make a financial windfall out of the accident. In this case the engineers, depending on how the legal system broke for them, could be looking at jail time or being independlently wealtnhy.
Fourth, Highway traffic signals are not all that uniform. How about making a left turn at a controlled intersection? You can go on a green, but first yielding to opposing traffic. Sometimes there is a sign reminding you to yield; sometimes not. If there is a signal that tells you when you can turn left, sometimes it is a green light and other times it is a green arrow. Sometimes the stop signal is a red light and sometimes it is a red arrow. Sometimes traffic turning and traffic going straight both have greens. Sometimes they don't. Sometimes the signals are mounted to the right, sometimes to the left and sometimes overhead. Sometimes the signals have light bulbs, sometimes LEDs and sometimes those highly focused signals you can't see from other lanes.
Shall the government standardize signal aspect and indications? Recently on Youtube I took a "train trip" riding the head end from Leipsig, Germany, to Nuremburg. I observed Germany's different color light systems, the older Hp (west) or Hl (east) and the newer Ks. I even saw several locations with semaphores. This is on a passenger-intensive double track mainline. Not exactly standardized
Take a look at the Canadian system. It is a lot more complex than anything in the USA. Not only do they have limited (45 MPH), medium (30 MPH), and slow speeds (15 MPH), they also have a newer "diverging" speed, (25 MPH.) Red over flashing green over steady green means something different than Red over steady green over flashing green.
When you standardize something, you limit the possibility that someone (or some railroad) will come up with something better.
It would be impossable to make a signalimg system too meet the needs of all railroads. Besides PTC will take over all freight-passenger lines by 2015.
The road to to success is always under construction. _____________________________________________________________________________ When the going gets tough, the tough use duct tape.
Consider the title query: "Why are U.S. Railroads resisting standardized signals?"
This question implies that some amorphous, unnamed and all-knowing government agency has asked the several carriers to standardize their signal systems. The title query also implies ("railroads resisting") that the carriers are not just resisting this "request," but actively colluding with one another, to forestall having to do so.
To respond, if, say, FRA (or any government agency which likewise wishes to impose its will over a bunch of greedy, profit seeking corporations -- think FDA, OSHA, EPA and the like) would have publicly urged or prodded the sluggardly carriers to adopt their measures, it would have conducted a lengthy publicity campaign -- speeches to labor organizations, shipper groups, leaks to the media -- to keep their request before the public and, more important, an ignorant Congress. This has not happened. Why not? Probably because the 'crats at FRA do not perceive an absence of railway signalling systems to be all that important in their ceaseless efforts to keep the rails safe for all of us.
With respect to the railroad industry that I grew up in, the "not invented here" mentality was alive and well. If our competitor uses product or system X, then by gar, we'll use Z. The idea that the carriers would collude in an area this arcane to preserve their right to purchase and employ (the military say deploy) the system they like best is ludicrous. Hey! They couldn't even collude competently to set their own rates.
But, speaking of ystems that need upgrading, the government-owned and operated air traffic control system is 40-some years old, uses vaccuum tubes instaed of solid state electronic, and some Third World -- yup, Third World -- countries have purchased more advanced systems than we have. Food for thought, and just a thought to leave us with...
Well, maybe another "beautiful theory murdered by a gang of brutal facts", or at least those devil-infested details. However, appreciating the time and thought of this repsonse, and continuing the discussion a little further, allow me to clarify and revise some aspects of it:
- Doesn't have to be nationwide - that may fairly be implied by what I wrote, but I didn't intend that. I know - then it's not uniform - but I'm just suggesting "more uniform" (whatever that means) - not total or blanket uniformity. (In my track-oriented world, the analogy would be something like requiring replacing all of the older heavy and still serviceable but now non-standard rail sections that are still in track with new 136-RE so that all the rail is the same - nice idea, but not necessary or cost-effective, doesn't improve anything much, etc.) Don's point is well-taken that a crew 1,500 miles away from the NEC doesn't need to know about the Amtrak flashing green for a high-speed cross-over. I believe that few (if any) railroad operating crews are responsible for more than several hundred miles of track from their home terminal, so if the rules are different on BNSF in Chicago than in LA, is there a real potential for harm there ? What I'm thinking of is more on a regional basis, esp. around Chicago, NYC, St. Louis, places like that where a crew could realistically have to run on several different railroads with several different signal systems in the course of a normal days work. Beyond that - use pilots.
- Degrading all the aspects to a lowest common denominator is not quite what I had in mind, either - certainly not to any point that the railroads would lose freight capacity, economic activity, and jobs. I take it that the concern here is something like discarding a high-speed system that uses multiple blocks and multiple signal heads, etc. for even farther advanced approach signals, back down to a simple 3-block R-Y-G system. Again, I'm not suggesting that level of uniformity. Instead, I see a distinction between a signal system that is supplemented with additional Aspects and Indications or is more sophisticated, with a system that has a flat-out conflict or incocnsistency or incompatibility in the Aspect or Indication with another local system. Kind of like the difference between the old simple 4-direction single-head highway traffic stoplight hanging over the middle of the intersection, and the modern multiple-head, multiple-phase turning lane intersections common in busy suburban areas. Yellow means it's about to turn Red, whether it's a solid light or a turn arrow.
- "Replacing the worst-case scenario installations with new equipment" - that's more like what I have in mind.
- A little while ago it occurred to me that perhaps Andy's point above can be restated thusly: "We've been depending on the 'soft-fix' of flexible humans to be the "work-around" or adapter between different or inconsistent signal systems, instead paying for and installing the 'hard fix' expenditure of wires, software, and new equipment." That's OK to some point, but with the building volume of rail traffic increasing the extent and frequency of such reliance on fallible humans for that coordination between signal systems may be having the unseen effect of chipping away at any built-in assumed and unstated institutional margin of safety. Such a dependence on humans is also inconsistent with and compromises the integrity of the intent of a fail-safe control system. My point - and perhaps Andy's too - is that we should view the system more broadly or holistically - it's more than just track circuits, relay cases, signals, and rule books. It also includes the humans whom we ultimately depend on to interpret and implement the mechanical parts in all kinds of conditions and across multiple territories. Although those components don't appear on a circuit diagram, we ignore the reliability of their function in the signal system at our peril.
- Not prepared to discuss the costs, potential benefits, and methodology or analyses of same until I have a better understanding of what the root problem is and the scope of likely possible solutions, and I know I'm not there yet (and may never be). I do concur completely with your point 1. about alternatives (although there are inherent disconnects there between what the railroads can do vis-a-vis society at large). To illustrate: If we put all of that $2 Billion into grade crossing protection upgrades - flashers and gates - we could do that at something like 8,000 to 10,000 crossings. That would put quite a dent in the hazardous crossing count and annual death toll from same - probably more so than such "fixes" to the signal systems ever would.
- Has any railroad, consultant, or government agency recently (last 15 years or so) and competently studied and reported on the actual cost* of eliminating the worst of the inconsistencies between signal indications ? Don't need to know who or when or any confidential or proprietary information - just curious what the NTSB or FRA may be getting us into if those recommendations are ever proposed to be implemented. If not, it might be a good idea for such a study to be done - if only as a defensive, self-preservation measure - to have "on the shelf" to be able to credibly argue the technical details and the cost-benefit problem to the FRA if it ever decides to mandate such a thing.
[* - Not challenging the basis or veracity of your figures, either.]
Enough for now - got to head off to something else. Good discussion - thanks for participating.
The call for a standardized national railroad signal system is a straw dog being used to advance a political agenda. Making an analogy to the case for the national system of highway traffic control devices is weak because railroad trainmen do not circulate over the entire U.S. railroad system as highway users do on the national highway system. And even at that, the national highway system varies state by state. For that matter, systems vary from county to county, and motorists travel roads all around the world.
There is no real such real thing as consistant natianal signal rules in large countries, exept possibly if the railway is government run nationaly and things have been fixed at ANY cost. Sure SMALL individual nations in Europe but collectively it still doesn't work there.
The railway network is NOT supposed to be at the cost of sending people to space with no return. It's supposed to be an ecconomical form of transport. In the USA it means large volumes of slower freight. In other countrys like Japan it may have a different meaning.,
I'm still agianst the "restriceing signal" indication for loaded passenger trains.
Also what if someone invents a better signal/control system then PTC before the entire network is completed? Do you complete the status plan or improve ther rest of the lines immediately making an inconsistant system again ?
Dumb question. If you do not have a standard signal system, Why not develop a data base on each rail line and the signal used on that line so that A strip map of signals could be displayed on a laptop. The crew would then be responsible for entering in the signal indications as they approached the signals and data base would in clear language state what the signal indication required and would also show track speed restrictions. This would be especially helpful for RR crews new to an area.
Rgds IGN
Railway Man Estimated costs for PTC have doubled in the last year, and then some; I would not be surprised to see the eventual cost in excess of $15 billion. Many people do not grasp that train-control systems are supposed to deliver efficiency as well as safety. It doesn't do much good to make the system so safe that the efficiency results in bankruptcy of the railways, unless, that happens to be your goal. The Class Is are determined to extract efficiency value from their multibillion dollar investment in PTC. That is going to be an interesting challenge. I haven't decided yet whether I'm having fun yet, though. RWM
Great. Just freaking great.
We've now got another government imposed very expensive solution in search of a problem. It isn't like the wealth needed to install this PTC boondogle is just laying there. It has to be created. Wasting the wealth (which you create through your work and investments) on projects such as PTC, which may or may not produce efficiencies to pay for itself, is not good economic sense. It will make us less well off.
Let's see, in this particular case a government employed locomotive engineer didn't understand a signal indication. A second government employed locomotive engineer was present and flat out told him he was wrong. He disregarded her, and in doing so blatently violated railroading's first commandment: "When in doubt, take the safe course of action." (If any part of his "reason" for disregarding her was based on the fact that she was "just a girl", it's sickening. Any man who thinks that way doesn't belong in any position of responsibility.)
The proposed solution to the government putting a less than adequate person in control of a loaded passenger train is, of course, a government mandated, very expensive, very wasteful, system that will reduce to an extent, but not totally eliminate, train collisions.
$15 billion is a lot of wealth to risk on an untried system that may or may not produce significant efficiencies. I think the goal may well be, as noted above, to bankrupt the railroads through this mandate. Then they will need government (as in our) money. This means governmet control. Not our control, although it will be our money (wealth). We won't have a thing to say about things. The connected power brokers will be in charge.
The neo-fascists will cheer.
We have a rulebook that outlines the signals we use. It is part of our job to KNOW what the signals mean. We run on the same territories over and over, so there aren't really "new crews" to an area. There comes a time when you have to stop dumbing down the craft and start hiring smarter people.
As far as standardizing: NS in the former conrail areas recently went from NORAC (a standardized rulebook for several RRs) to their own "hillbilly" rulebook. But it had to have extra pages added to take into account the former Conrail signals. Sigh.
narig01 Dumb question. If you do not have a standard signal system, Why not develop a data base on each rail line and the signal used on that line so that A strip map of signals could be displayed on a laptop. The crew would then be responsible for entering in the signal indications as they approached the signals and data base would in clear language state what the signal indication required and would also show track speed restrictions. This would be especially helpful for RR crews new to an area. Rgds IGN
Paul d north I have read your rants on here for 2 pages now like a teenager know-it-all and not listening to anything. Then you stated above that your not wanting standardization country wide just maybe in places like chicago st.louis nyc bla bla bla. Listen up. the signals are standard and when you get into yard limits its is really more standard. I said in my post ( if you cared to read it) that im qualified on over 350 miles of trackage, and run over 7 differant railroads and the signal systems they use. I run in st.louis and I cant recall any big wrecks due to signals. and that is the first in chicago i ever heard of. Now about 2 years ago the trra in st.louis changed the signals on thier property. it took 1 trip to get familar with the indications they use. they use basic abs then tc control and now a system that the UP uses ( gcor maybe) regaurdless ive past the test 100% conductors ive worked with and listen to on the radio still dont call them right and they have the know - it - all mentality ( meaning you cant tell them anything) . Now For what people are missing here. You can have signals for anything and that your blaming the signals for the wreck. but when you run on someone elses road they have time table instructions, and if you remeber there is a thing called a rule book ( I know you know what im saying you recited from that bible several times) In that rule book there is a rule stating that In yard limits when running on anything other than a clear is to be considered a restricting signal.
Wabash....well said. In any job there are responsibilities that are attached to that job. You are supposed to know the rules. This person didnt. Nor did this person take the advice of a qualified engineer in the cab. Even if there was a disagreement over the signals, why didnt the engineer at least take the "safe course"?
I have a little reading on this to do this weekend to get up to speed, but several frightening questions are beginning to develop including why was this engineer allowed to operate on a railroad in which he did not understand the rules? In a area as congested as Chicago, it was only a matter of time before the "restricting" aspect would have been faced.
Nor do I care that the relief engineer "was a girl" in a man's environment. She had a responsibility to the passengers. When in question, whip out the CORA and put it in his face. "THIS IS A RESTRICTING SIGNAL. SHUT THIS TRAIN DOWN NOW."
Regarding the PTC system...are there no efficiency studies indicating the ROI?
They already have that -- it's the signal aspects and indications page in their employee timetables. No battery required.
MP173Regarding the PTC system...are there no efficiency studies indicating the ROI? ed
Sort of ... there's been some efforts to look at it. But since the details of the implementation are very complex and affect just about everything that happens on the railway (for example, hundreds of people are at present trying designing the communications systems protocols and architecture) it's not possible yet to project with accuracy the effects or the costs. The industry consensus, however, remains that PTC may generate a net positive cash flow when it's all said and done. But the intrinsic manner in which the positive benefit will be distributed across the railway industry will not raise all boats equally.
greyhounds Great. Just freaking great. We've now got another government imposed very expensive solution in search of a problem. It isn't like the wealth needed to install this PTC boondogle is just laying there. It has to be created. Wasting the wealth (which you create through your work and investments) on projects such as PTC, which may or may not produce efficiencies to pay for itself, is not good economic sense. It will make us less well off. Let's see, in this particular case a government employed locomotive engineer didn't understand a signal indication. A second government employed locomotive engineer was present and flat out told him he was wrong. He disregarded her, and in doing so blatently violated railroading's first commandment: "When in doubt, take the safe course of action." (If any part of his "reason" for disregarding her was based on the fact that she was "just a girl", it's sickening. Any man who thinks that way doesn't belong in any position of responsibility.) The proposed solution to the government putting a less than adequate person in control of a loaded passenger train is, of course, a government mandated, very expensive, very wasteful, system that will reduce to an extent, but not totally eliminate, train collisions. $15 billion is a lot of wealth to risk on an untried system that may or may not produce significant efficiencies. I think the goal may well be, as noted above, to bankrupt the railroads through this mandate. Then they will need government (as in our) money. This means governmet control. Not our control, although it will be our money (wealth). We won't have a thing to say about things. The connected power brokers will be in charge. The neo-fascists will cheer.
I don't think it's entirely fair to call it untried -- I've been around it long enough to have confidence it will work. This is not saying that someone can just run over to Best Buy, plug it in, and turn it on. There's a lot of work to do, but I don't think anyone in the rail industry involved in PTC is dubious that we can't resolve all the details.
Railway Man I don't think it's entirely fair to call it untried -- I've been around it long enough to have confidence it will work. This is not saying that someone can just run over to Best Buy, plug it in, and turn it on. There's a lot of work to do, but I don't think anyone in the rail industry involved in PTC is dubious that we can't resolve all the details. RWM
spokyoneBut just when everyone thinks all the details have been resolved, a string of events will occur in a certain way that no one thought of, then a crash will occur because we do not have an experienced human in charge
PTC hasn't been touted as a replacement for a live crew yet.
But never underestimate the ingenuity of the human mind. If a crew member can figure out a way to circumvent the system and make their job "easier," they will, until something happens (usually bad) to expose it.
Railway Man MP173 Regarding the PTC system...are there no efficiency studies indicating the ROI? ed Sort of ... there's been some efforts to look at it. But since the details of the implementation are very complex and affect just about everything that happens on the railway (for example, hundreds of people are at present trying designing the communications systems protocols and architecture) it's not possible yet to project with accuracy the effects or the costs. The industry consensus, however, remains that PTC may generate a net positive cash flow when it's all said and done. But the intrinsic manner in which the positive benefit will be distributed across the railway industry will not raise all boats equally. RWM
MP173 Regarding the PTC system...are there no efficiency studies indicating the ROI? ed
This, of course, also means that it may not generate a net positive cash flow.
$15 Billion is an awfully big bet on something that no one has good confidence in.
Railway Man greyhounds Great. Just freaking great. We've now got another government imposed very expensive solution in search of a problem. It isn't like the wealth needed to install this PTC boondogle is just laying there. It has to be created. Wasting the wealth (which you create through your work and investments) on projects such as PTC, which may or may not produce efficiencies to pay for itself, is not good economic sense. It will make us less well off. Yadda, Yadda, Yadda. (I edited out some stuff here) $15 billion is a lot of wealth to risk on an untried system that may or may not produce significant efficiencies. I think the goal may well be, as noted above, to bankrupt the railroads through this mandate. Then they will need government (as in our) money. This means governmet control. Not our control, although it will be our money (wealth). We won't have a thing to say about things. The connected power brokers will be in charge. The neo-fascists will cheer. I don't think it's entirely fair to call it untried -- I've been around it long enough to have confidence it will work. This is not saying that someone can just run over to Best Buy, plug it in, and turn it on. There's a lot of work to do, but I don't think anyone in the rail industry involved in PTC is dubious that we can't resolve all the details. RWM
greyhounds Great. Just freaking great. We've now got another government imposed very expensive solution in search of a problem. It isn't like the wealth needed to install this PTC boondogle is just laying there. It has to be created. Wasting the wealth (which you create through your work and investments) on projects such as PTC, which may or may not produce efficiencies to pay for itself, is not good economic sense. It will make us less well off. Yadda, Yadda, Yadda. (I edited out some stuff here) $15 billion is a lot of wealth to risk on an untried system that may or may not produce significant efficiencies. I think the goal may well be, as noted above, to bankrupt the railroads through this mandate. Then they will need government (as in our) money. This means governmet control. Not our control, although it will be our money (wealth). We won't have a thing to say about things. The connected power brokers will be in charge. The neo-fascists will cheer.
Yadda, Yadda, Yadda. (I edited out some stuff here)
You are most correct. I should have worded that better. I should have used the word "unproven" instead of the word "untried".
What I was trying to say was that PTC has not been shown to produce the sufficient efficiencies required to justify its huge cost when adopted on a universal basis as mandated by the government. It was a failure on my part to properly express my thoughts. I apologize.
I too have been around long enough to have great confidence that the PTC system can be made to work. All it will take will be a lot of money, time and effort. What I have no confidence in is a command economy under which the universal adoption of PTC is mandated by the government instead of being adopted on a case by case basis after a careful cost/benifit analysis done by the entity that will bear the cost and enjoy the benifits. Will the benifits outweigh the costs of the money, time and effort spent on this thing? Who the Hell knows? And $15 Billion is one Hell of a bet on something that has never been proven to produce significant savings on a universal basis.
If I had to bet my own money, and I do bet my own money from time to time, I'd bet that PTC has a high probability of paying off on busy routes such as the Northern Transcon west of Casselton, ND where the double track ends. I'd also bet that it has almost no probability of paying off on low density lines such as CN's Iowa line. So why the mandate for universal adoption?
I'll refrain from going political here.
tree68But never underestimate the ingenuity of the human mind. If a crew member can figure out a way to circumvent the system and make their job "easier," they will, until something happens (usually bad) to expose it.
When you build an idiot-proof system, the universe responds by creating more ingenious idiots.
Greyhounds and Andy:
Actually the safety value of PTC can be calcuated with a good level of precision. The structure-and-logic goes like this:
Effects of PTC and whether they are net cash flow positive are:
Net-net: positive enough that the Class 1s did not flinch to much when the RSIA passed, did they?
Two observations:
Lawsuits costs have reached the point where awards are well beyond reasonable damages (yes I hear you - what is reasonable). Lawsuits are filed for frivolous claims and some tort lawyers encourage them because a settlement is too frequently made just to avoid the costs even though the defendent would likely win. If we adopt the UK system where the loser in a civil suit has to pay the winners costs much of this would go away. Therefore litigation costs are too inflated and should be judged accordingly in any cost/benefit analysis.
We should recognize the cost of bureaucracy in enforcing these mandates knowing up-front that bureaucracies almost never go away. How long before the ICC went away and was then replaced by another bureaucracy? The administrative costs, and the always present bureaucratic inefficiency, are huge. And even these costs do not take into account the cost of these employees after they retire with a very short span of actual working time. Just talk to the retired government employees who have worked twenty years and retired to see what a deal they have. And some double-dip by taking another government job.
So perhaps positive train control should be slowly initiated where passenger service operates, but on commuter lines first where the passenger density is greatest.
Diningcar:
I have to project costs given likely outcomes -- and a massive re-ordering of the U.S. method of assessing and costing liability is not a likely outcome. There's no will by the public for it, in fact, the public seems to be more interested in making even more certainty that if anything goes wrong, someone will pay.
Ironically it's the lack of an FRA bureaucracy to administer PTC that worries us. There's no assurance that the FRA will be able to turn around in a timely manner the flood of documentation it requires. But once the systems are implemented, the FRA oversight and required bureaucracy is pretty minimal. I don't see a long-term monster here.
I think the possibility that PTC will be concentrated on commuter lines will "come to the front" when the resources are allocated -- because there won't be enough people to make this happen everywhere on the timetable requested in the Rail Safety Improvement Act.
Railway Man Greyhounds and Andy: Actually the safety value of PTC can be calcuated with a good level of precision. The structure-and-logic goes like this: Assess historic rates and rates-of-change of occurrence for authority excursions including work-zone violations, open-switch derailments, and overspeed derailments. Project the percentage at which these result in property damage or human casualty using historic factors. Assess using historic factors and current-day multipliers the cost of these events. Determine which types of these events are likely to be prevented by PTC. Compare that to the overall rate. Determine a multiplier (less than 1.0). Factor in the cost of money. Factor in the trend rate of tort claim values (multiplier may or may not be greater than 1.0) Build a formula, plug in the variables. Use statistics to determine confidence intervals. [emphasis added - PDN; snip of list of PTC effects on net cash flow]
[emphasis added - PDN; snip of list of PTC effects on net cash flow]
For what it's worth, I understand that insurance carriers - in evaluating the proabable costs of future claims - take the following approach, such as for worker's compensation, automobile, and general liability:
A. Evaluate and determine the frequency or probablility of accidents or events (1. above);
B. Assign a likely typical cost to each event, based on historical experience (3. above, plus maybe 6. above, too).
C. Multiply A times B = likely claims.
Note that this excludes the effects of 2. = percentage of events that cause property damage or casualty (injury or death). The basis for this - as I understand it - is that any accident has the potential for being costly; whether it actually turns out to be or not (i.e., "no harm - no foul - no cost") is a matter of fortunate happenstance. As such, any accidents or events with minimal damage payouts are not something to be relied upon for the insured's benefit (and to the insurance company's possible future detriment) - essentially, the insured's past good luck. From the insurance company's perspective, most of the risk is in the happening of the accident or event in the first place, not the magnitude of the resulting damages.
Personally, I disagree with this approach, at least when the statistical sample is large enough - I think the methodology outlined by RWM above is more defensible. Interestingly, that methodology also generally parallels the theory and procedure of the legal system and the classic 4-stage trial process for determining the amount of damages in tort/ negligence-type claims: First, determine fault (1 - duty & 2 - breach of same ) = happening of the accident; next 3 - causation/ responsibility (the PTC analysis might not need to take that into account, though - just assumes that the RR will be 100 % responsible); then 4 - damages ($ amount); and lastly, any "special damages" (punitive damages additive or multiplier, attorney's fees, etc.). As such it will seem pretty familiar to that community of reviewers and "stakeholders".
As to diningcar's comment regarding the "beyond reasonable" magnitude of present-day tort awards: Certainly that's true, but any analysis of alternatives should use those higher figures anyway, at least until it's clear that they've gotten back under control. Otherwise, for example, the administrative risk is that the reserve for claims will be drastically underfunded - say, they were calculated at an avergae of $500,000, but have turned out to be $1 million each. Here, the decision risk is that the wrong or a less-than-optimum decision will be made because the wrong values were used for data inputs. That would result in skewing the selected alternate towards less PTC and more risk of claims. However, the claims will then be higher than anticipated, so the system will appear to be not performing as well as expected or promised.
Of course, using the current inflated levels of tort claims in the analysis will have a skewed effect, too - more safety equipment (PTC) than would be objectively justified from a realistic view of the probable damage payouts. Nevertheless, that is more defensible position and result - if you think differently, read a history of the mid-1970's Ford Pinto gas tank fires, and the punitive damage awards for the resulting injuries. That happened when it was discovered and presented to the juries that - horrors* ! - those cold*, calculating Ford engineers and risk managers had actually assigned a dollar value to human lives, and then calculated the risk of injury and death claims from using thin-shelled gas tanks vulnerably mounted near the rear axle - all in the name of light weight and better fuel mileage, of course. We wouldn't want to risk that happening to the RR industry now, would we ?
[* - some cynicism and heavy sarcasm in here]
Railway Man A quick point on PTC: 99% of the U.S. will be one of two systems. The "Class 1" universe will all be on a Wabtec platform, which is locomotive-based, peer-to-peer with wayside interface units. UP is proceeding on a "vital" pathway where the PTC will be its own Method of Operation whereas BNSF is proceeding on a "non-vital" pathway with the PTC being an overlay on existing Methods of Operation such as CTC and TWC. NS appears so far to be leaning toward the vital path, CSX hasn't announced, and CN, CPR and KCS are not yet to that level of analysis. The Northeast Corridor universe will all be on the ACSES platform, which is a development of existing cab-signal systems. A few railroads which do not touch either of those universes can do something else, for example, the Alaska Railroad is well along on a US&S wayside-based platform. Some of the commuter railways are stating they would prefer an evolved intermittant cab-signal system such as what GETS has provided for TriMet on the new Beaverton-Wilsonville, Oregon, commuter line. But if they touch a Class 1, that probably won't fly unless they want to dual-equip. Estimated costs for PTC have doubled in the last year, and then some; I would not be surprised to see the eventual cost in excess of $15 billion. Many people do not grasp that train-control systems are supposed to deliver efficiency as well as safety. It doesn't do much good to make the system so safe that the efficiency results in bankruptcy of the railways, unless, that happens to be your goal. The Class Is are determined to extract efficiency value from their multibillion dollar investment in PTC. That is going to be an interesting challenge. I haven't decided yet whether I'm having fun yet, though. RWM
spokyoneWill the systems you mentioned still allow a dispatcher to enable two trains to occupy one block for efficiency? (Pere Marquette)
Will the systems you mentioned still allow a dispatcher to enable two trains to occupy one block for efficiency? (Pere Marquette)
Yes, just like it's done everywhere in the U.S. at present. In some cases both trains will be at restricted speed, in other cases only the following train.
Maybe it's just me on a Monday, but I took spokyone's question as having a dose or irony or cynicism in it - the Pere Marquette reference as being to the Amtrak train that collided with a stopped NS intermodal train ahead of it, after passing a "Restricting" signal (15 MPH max., and able to stop within 1/2 range of vision, etc.) to allow it to close up on the NS train, because the Amtrak engineer mistakenly interpreted the signal as "Approach" (30 MPH max, able to stop at next signal).
So, a few clarifying questions:
Would PTC's enabling the DS to permit 2 trains in the same block defeat the purpose of PTC and still allow this kind of accident to happen ? My understanding is that no, it won't, because:
A) PTC will keep a "tighter leash" on the following train when the DS allows a following train into an occupied block, by enforcing the actual speed limits of the signal - not over 15 MPH, instead of the mistaken 30 MPH (let alone the actual 40 MPH that the Amtrak train got up to); and,
B) PTC will also "know" where the rear of the preceding train is, and so how far the head end of the following train has to go before they would collide, as well as the braking performance ("curve") of the following train. Thus, PTC will continuously monitor the situation (via GPS, track "tags", and axle "distance" counters, etc.) and if the following train gets close to not being able to "stop within 1/2 range of vision" for that speed, the the PTC will enforce that as well by making a brake application.
Are my understandings above correct, or am I missing something here ?
Now for the zinger: How wil the PTC know or deal with the "range of vision calculation" ? Suppose at 15 MPH the stopping distance for the following train is 500 ft. (made-up value for this question). But, account of site (and sight) conditions - such as on a sharper curve and on the inside of the cruve is either a parallel retaining wall, train with high cars on an adjacent track, and/ or close vegetation - the range of vision is less than twice that stopping distance - say, less than 1,000 ft. Or worse yet, say the sight distance is less than the actual 500 ft. stopping distance - I could see (pun !) that happening with the train-on-adjoining-inside-track scenario. Will the PTC be programmed to be able to take such things into account - that the sight distance might be restricted by "permanent" site conditions at certain locations such as the retaining wall, semi-permanent such as the vegetation (kind of like a temporary "slow order"*), or really temporary and transient conditions like the train on the adjoining track ? What a programming and implementation headache/ nightmare that could / will be ? Wow . . .
[* - not going to think about adjusting the vision range calculation for vegetation conditions as the deciduous leaves change each season - unless arborists are going to be hired as well to implement this ? ]
Any thought or responses will be interesting, I'm sure. Thanks.
I'm just guessing here, but what the heck?
As Paul suggests, there will be a number of things that will have to be considered in setting up PTC for a particular line. Most will have to do with authorized track speed and layout, dynamics for each specific train, and, of course, track occupancy.
I should think, though, that at some point each line will have to go through a process analogous to the fellow who drives down the road and decides where the no passing zones are going to be - by seat-of-the-pants eyeballing the line. Granted, some situations will be constantly changing, but that may be something the PTC system can process, enforcing a different set of parameters if an adjacent track is shown as occupied.
Those areas where local geography is a factor (seasons notwithstanding) might essentially get hard coded into the system, just like any permanent track feature.
Andy -- the simple answer is, yes, it will enable "floating blocks". The reality is that I don't think floating blocks will be implemented at first, because it requires a very significant increase in complexity of the PTC implementation (which already is quite complex). And ultimately, I do not think that floating blocks will be implemented in the forseable future at all, except in some set-piece systems such as subways (which are not "railways" by the FRA definition) because (1) it's very hard to actually turn this feature into an actual time-saving advantage in the real world, and (2) a railway operated in such a fashion that floating blocks could be used advantageously is probably a very poorly run railway in the first place, and it's much easier and cheaper to just operate it properly and not get into this situation where floating blocks matter.
Think of it this way: how do you put a floating block to your advantage? If you go back and look at those presentations, they envision a railway world consisting mostly of double-track main lines of almost indefinite distance innocent of intermediate stops and speed restrictions for curves and speed losses for ascending and descending grades. Do you know of any railways like that? I don't. It's the entry and exit points to the double-track where the floating block fails, because it bounds them, and the curve and grade speed losses, because those bunch up trains on the entry and stretch them out on the exit. All the floating block enables is the bunching of trains to occur more quickly and with a little less space in between. You can't feed trains into the system at one end at the minimum block spacing because they can't accelerate fast enough to ever catch up to the preceding train, unless for some inexplicable reason you decided to let the slowest train out first.
OK, so it does enable a fast train to come up behind a slow one. So why are you running a slow train out in front of a fast one anyway? So now you've saved a couple of minutes in the following train not having to wait for the preceding train to pass 2 block lengths but so what -- in a few minutes the fast following train will catch up and have to cool its heels.
And, if it's a mixed freight-passenger railway, how do you write the passenger schedule to turn this advantage into regular every-day time savings? Only if you are predicting there will be a slow freight out there every day. Why would you do that?
At best the floating block, in a Class 1 type railway, saves a couple minutes here or there every so often, and helps passenger trains recover from delays. But it can't create savings in a passenger schedule, except on a subway type operation, where you can write this into the schedule and every day you have highly predictable operations. So I don't see how the cost-benefit ratio of floating block can ever pan out for a Class 1 type railway.
The floating block concept provides value in a railway world where the trains could be beneficially operated on 8,000' headways vs. 20,000' headways, if only you had floating blocks. But from my experience, even if you had floating blocks, it's neither practical nor economically desirable to operate a railway in such a manner as would be required to take advantage of them.
tree68I'm just guessing here, but what the heck? As Paul suggests, there will be a number of things that will have to be considered in setting up PTC for a particular line. Most will have to do with authorized track speed and layout, dynamics for each specific train, and, of course, track occupancy. I should think, though, that at some point each line will have to go through a process analogous to the fellow who drives down the road and decides where the no passing zones are going to be - by seat-of-the-pants eyeballing the line. Granted, some situations will be constantly changing, but that may be something the PTC system can process, enforcing a different set of parameters if an adjacent track is shown as occupied. Those areas where local geography is a factor (seasons notwithstanding) might essentially get hard coded into the system, just like any permanent track feature.
Larry and Paul: ALL the local geography is coded into the system. Every feature of the track configuration. Every change in horizontal and vertical geometry. Every signal. Every insulated joint.
The braking algorithms are developed for the individual train's Tons Per Operative Brake and the on-board computer calculates the braking distance to a target stop on a real-time basis, because it knows where the train is in space, and the characteristics of the vertical geometry. (It's the same calculation that I perform to space wayside signals for a given aspect system.) The system knows where the other trains are too, and the other authorities, the position of switches, the aspects of signals, and so forth. It calculates all this. The architecture of the logic is not complex. The hard part is making sure that the system for publishing updates to the onboard computers is robust and doesn't chew up too much bandwidth.
Paul_D_North_JrMaybe it's just me on a Monday, but I took spokyone's question as having a dose or irony or cynicism in it - the Pere Marquette reference as being to the Amtrak train that collided with a stopped NS intermodal train ahead of it, after passing a "Restricting" signal (15 MPH max., and able to stop within 1/2 range of vision, etc.) to allow it to close up on the NS train, because the Amtrak engineer mistakenly interpreted the signal as "Approach" (30 MPH max, able to stop at next signal). So, a few clarifying questions: Would PTC's enabling the DS to permit 2 trains in the same block defeat the purpose of PTC and still allow this kind of accident to happen ? My understanding is that no, it won't, because: A) PTC will keep a "tighter leash" on the following train when the DS allows a following train into an occupied block, by enforcing the actual speed limits of the signal - not over 15 MPH, instead of the mistaken 30 MPH (let alone the actual 40 MPH that the Amtrak train got up to); and, B) PTC will also "know" where the rear of the preceding train is, and so how far the head end of the following train has to go before they would collide, as well as the braking performance ("curve") of the following train. Thus, PTC will continuously monitor the situation (via GPS, track "tags", and axle "distance" counters, etc.) and if the following train gets close to not being able to "stop within 1/2 range of vision" for that speed, the the PTC will enforce that as well by making a brake application. Are my understandings above correct, or am I missing something here ? Now for the zinger: How wil the PTC know or deal with the "range of vision calculation" ? Suppose at 15 MPH the stopping distance for the following train is 500 ft. (made-up value for this question). But, account of site (and sight) conditions - such as on a sharper curve and on the inside of the cruve is either a parallel retaining wall, train with high cars on an adjacent track, and/ or close vegetation - the range of vision is less than twice that stopping distance - say, less than 1,000 ft. Or worse yet, say the sight distance is less than the actual 500 ft. stopping distance - I could see (pun !) that happening with the train-on-adjoining-inside-track scenario. Will the PTC be programmed to be able to take such things into account - that the sight distance might be restricted by "permanent" site conditions at certain locations such as the retaining wall, semi-permanent such as the vegetation (kind of like a temporary "slow order"*), or really temporary and transient conditions like the train on the adjoining track ? What a programming and implementation headache/ nightmare that could / will be ? Wow . . . [* - not going to think about adjusting the vision range calculation for vegetation conditions as the deciduous leaves change each season - unless arborists are going to be hired as well to implement this ? ] Any thought or responses will be interesting, I'm sure. Thanks. - Paul North.
Railway Man [snip; emphasis added - PDN.] The hard part is making sure that the system for publishing updates to the onboard computers is robust and doesn't chew up too much bandwidth. RWM
Off-the-wall - and maybe a little off-topic - but: I'm wondering if the "system for publishing updates to the onboard computers" is analogous or comparable at all to the U.S. Army's IVIS = "Inter-Vehicle Information System" ?
Briefly, as I understand it, IVIS keeps track of each vehicle's location via GPS and broadcasts it to all of the other vehicles so that they all know where all the others are - that's for both tactical control by the unit commanders, and to prevent "friendly fire" ("blue-on-blue") incidents. IVIS is also part of the Combat Vehicle Command and Control System ("CVCC") also monitors the functional status of the vehicles (fuel, ammo, etc.) and communicates that to the commander and support units to make necessary logistical arrangements for resupply when necessary, etc. Additionally, the scout units can input the observed location and other data pertaining to terrain and opposition forces into IVIS, again so that all involved have that data. Most combat vehicles (Abrams tanks, Bradley infantry fighting vehicles, artillery, scout units, etc.) were equipped with IVIS starting in the early 1990s.
Here's a link to a reference for a publication regarding it, titled "SIMNET CVCC Software Design Document", June 1991 (61 pp.):
http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=ADA244222
Just for what it's worth - the above is about all I know about it, but the similarity struck me, and I thought it would be interesting to ask. Anything too technical would be over my head, and I can see where some aspects might be proprietary or senstiive, so I'm not necessarily expecting a reply - just "FYI" is all.
Paul -- the communications technology envisioned is encrypted 802.11. The "transmission" is not the problem so much as the collection, verification, and authentification of the data, and the implications one piece of data has on all the other pieces of data and on the system's operability.
For example, suppose a new industry turnout is to be cut into the main track one day. That will require:
All of this stuff has difficult timing sensitivities. It's not like a retail store or an airline, where every day the whole operation stops dead, everyone runs around putting things right, and all the databases can be updated with the day's events and the next day, we turn the system back on, and start afresh. We can't stop the railway every night, so this all has to be done in real time but it cannot have huge effects on operating efficiency and cost.
The real problem with PTC is not the technology. That part is reasonably straightforward. The problem is managing the system updates in a way that is both effective and efficient.
Railway Man Paul: PTC enforces the authority and the track civil speed limit, not the signal aspect. It really doesn't matter what the signal aspect is other than the absolute signal displaying "stop." If the PTC thinks the train can operate safety at a higher speed than an intermediate aspect would otherwise allow, it knocks down the maximum so there's not a conflict with the aspect. PTC actually works better than "limit of vision" because it knows what the track features are. The rear end of a train is the same thing to PTC as an absolute signal indicating stop. Both are "targets." [emphasis added - PDN; snip] RWM
[emphasis added - PDN; snip]
Thanks ! for the detailed reply - I'm definitely "getting understanding" here. However, I'd like to ask for a clarification regarding how PTC works in 1., as follows:
Suppose the track's civil speed limit is 60 MPH, but account of a train still leaving the far end of the 2nd block ahead at 45 MPH, the lineside signal's Aspect is "Approach" which indicates "30 MPH max., prepared to stop at the next signal". My understanding from the above is that the PTC would internally reset the maximum allowed speed for the following train - "knocks down the maximum" - from the 60 civil speed limit to the 30 MPH per the signal "so there's not a conflict with the aspect". Is this correct ?
I realize that with PTC fully implemented this may become a moot point - the lineside signals will disappear and so PTC won't have to coordinate with them and PTC's control will govern - but in the meantime this might be a useful way to understand how the logic of the PTC will work and handle such situations.
2. After my earlier post, I thought about it some more and concluded much the same - probably the "1/2 of the range of vision" criteria of the rule for a "Restrictingg" Indication will be discarded because it's too fact-specific and vague for any location, and can be superseded by "hard data" stored in the system for anything except maybe a yard track. For my examples above, that may require coding in the worst-case scenario of restricted vision account of trains on adjoining tracks and the like - as Larry noted, having a guy ride the territory to log and enter those kinds of things - but that would be the conservative, predictable, and safest way to provide for those scenarios. It just seemed like something the system would have trouble easily adapting to. To get around that so it won't have to, we'll come up with another way that works as well or better.
Thanks again.
RWM -
Thanks once again for the detailed reply to my "IVIS" post above. Since I come from an industrial siding background, that is a particularly apt example for me. The scope and details of that update is quite different - far more extensive and complicated - from what I had envisioned.
As you said, in this instance the challenge is not the technology, it's the management and administration of the institutions and people that use and rely on it - that's not a new one, either. Plus, the unavailability of the "Game over !" / restart / reboot freedom to the 24 x 7 railroad operations when trying to insert and synchronize this is kind of like replacing parts on an engine while it's still running, eh ?
I sincerely hope you're enjoying responding to these questions and comments as much as I'm learning from them. Thanks again for sharing your time and knowledge with all of us.
Best regards,
Paul_D_North_JrThanks ! for the detailed reply - I'm definitely "getting understanding" here. However, I'd like to ask for a clarification regarding how PTC works in 1., as follows: Suppose the track's civil speed limit is 60 MPH, but account of a train still leaving the far end of the 2nd block ahead at 45 MPH, the lineside signal's Aspect is "Approach" which indicates "30 MPH max., prepared to stop at the next signal". My understanding from the above is that the PTC would internally reset the maximum allowed speed for the following train - "knocks down the maximum" - from the 60 civil speed limit to the 30 MPH per the signal "so there's not a conflict with the aspect". Is this correct ?
This scenario is fairly easy to describe. The "target" for the following train is the last red block signal behind the preceding train, not the rear of the preceding train (we're not doing floating blocks just yet). The following train has to be at a speed at which it can stop short of that target, without fail. Signal aspect degradations are designed to provide safe braking distances for the maximum speed differential between any two possible aspects on a given pair of signals, which is usually 30 mph.
Let's assume the preceding train is dawdling out of that block so the condition is static for the following train. In that case, in the usual 4-aspect system, the first signal aspect less favorable than Clear is (for example) Flashing Yellow, Advance Approach, reduce to 40 mph. Some railways will set their PTC system to enforce 40 mph at the signal mast, others to enforce 40 mph after the signal mast but before it reaches the next mast. The next signal encountered will display hard Yellow, Approach, reduce to 30 mph. Again, some railways will set their system to enforce before the mast and some after the mast.
Thus, if there are two empty blocks between the occupied block and the block the following train is in, the two signals will be spaced each so that there is enough block distance for a train to safely brake from 30 to 0. The only question is whether to enforce 40 mph at the mast or beyond the mast; either way, the scenario you describe where a train is traveling merrily along at 60 mph beyond the FY aspect without initiating braking isn't allowed under signal rules or under PTC because that would put it into the back of a train just beyond a red signal.
I realize that with PTC fully implemented this may become a moot point - the lineside signals will disappear and so PTC won't have to coordinate with them and PTC's control will govern - but in the meantime this might be a useful way to understand how the logic of the PTC will work and handle such situations.2. After my earlier post, I thought about it some more and concluded much the same - probably the "1/2 of the range of vision" criteria of the rule for a "Restrictingg" Indication will be discarded because it's too fact-specific and vague for any location, and can be superseded by "hard data" stored in the system for anything except maybe a yard track. For my examples above, that may require coding in the worst-case scenario of restricted vision account of trains on adjoining tracks and the like - as Larry noted, having a guy ride the territory to log and enter those kinds of things - but that would be the conservative, predictable, and safest way to provide for those scenarios. It just seemed like something the system would have trouble easily adapting to. To get around that so it won't have to, we'll come up with another way that works as well or better. Thanks again. - Paul North.
PTC won't be installed on yard tracks, only main tracks and controlled sidings.
Let me repeat: There is no need to ride the territory to log and enter "safe braking distances" and in fact that is a terrible idea. The computer knows the train weight, and it knows the vertical profile, which makes it a simple calculation to determine maximum speed for the train when it is at any given point and still be able to stop short of a target. The computer displays the speed in the cab, and enforces if it is exceeded. Again, I do these calculations manually on an Excel chart preprogrammed with the formulas for the specific railway by inserting the average grade between any two points, inserting the desired TPOB, and hitting "calculate."
It will be up to the railways to decide how they want to deal with signal indications for "proceed at restricted speed." Most of them I think will simply enforce to 20 mph (or 15, or whatever they are) at the point where the train passes the signal mast, and then give a target speed beyond that signal that could well be 20 mph all the way if the computer determines there is no target beyond the signal before the next signal, or to a stop short of a target within that block, whichever is less.
In other words, the requirement that "movement must be made at a speed that allows stopping within half the range of vision short of train, engine, railroad car, men or equipment fouling the track, stop signal, or derail or switch lined improperly," might disappear on a main track. It depends on how railways will deal with work zone limits on adjacent tracks.
Railway Man Let me repeat: There is no need to ride the territory to log and enter "safe braking distances" and in fact that is a terrible idea. The computer knows the train weight, and it knows the vertical profile, which makes it a simple calculation to determine maximum speed for the train when it is at any given point and still be able to stop short of a target. The computer displays the speed in the cab, and enforces if it is exceeded. RWM
Let me repeat: There is no need to ride the territory to log and enter "safe braking distances" and in fact that is a terrible idea. The computer knows the train weight, and it knows the vertical profile, which makes it a simple calculation to determine maximum speed for the train when it is at any given point and still be able to stop short of a target. The computer displays the speed in the cab, and enforces if it is exceeded. RWM
Murphy SidingRailway Man Let me repeat: There is no need to ride the territory to log and enter "safe braking distances" and in fact that is a terrible idea. The computer knows the train weight, and it knows the vertical profile, which makes it a simple calculation to determine maximum speed for the train when it is at any given point and still be able to stop short of a target. The computer displays the speed in the cab, and enforces if it is exceeded. RWM Will/can the computer allow for changes in track conditions? The only one I can think of, off the top of my head, is wet leaves on the track, or something similar that would affect braking. Is something like that even an issue?
That's an astute question. Standard braking algorithms such as what we use for signal spacing assume worst-case conditions. But in the real world, rarely do trains actually brake as badly as the standard algorithm. However, the computer doesn't know that. It knows only what a worst-case scenario is, and since it's programmed to choose the safest course possible, it will choose a worst-case scenario. Thus, if the standard algorithm is instituted as the best-case condition (instead of relying upon the engineer's judgment as actually happens in the real world today), then the track capacity loss becomes rather significant. Trains end up running much more slowly and further apart then they do today.
Accordingly, there's a lot of research work ongoing into devising ways to measure a train's actual response curve along with local conditions (e.g., wet rail, presence of flange lubricators, rail head profile shape, etc.), with the goal of making braking curves more like what a good hoghead would use. The TTCI is doing some good work on this right now.
Wouldn't the goal be to never actually use the override functions of PTC?
Unless we're talking about eliminating the hand of the engineer on the controls, it would seem to me that a PTC override should rarely even happen. The system may provide the engineer with "signal indications," but if he/she is doing his job, PTC would never make a brake application because the engineer would already have the train at or below the recommended speed for the situation.
tree68Wouldn't the goal be to never actually use the override functions of PTC? Unless we're talking about eliminating the hand of the engineer on the controls, it would seem to me that a PTC override should rarely even happen. The system may provide the engineer with "signal indications," but if he/she is doing his job, PTC would never make a brake application because the engineer would already have the train at or below the recommended speed for the situation.
If you're talking about "enforcement" when you say "override," you're correct. The goal is to operate the train without a braking enforcement. The railway selects the tolerance level between target speed and actual speed. For example, at 0 mph over target speed it flashes a warning. At 3 mph over target speed it enforces braking. The computer knows what the condition is of the brake pipe (whether there's any reduction already made) and figures that into the speed tolerance calculation. Thus for example if it sees a 4 mph speed overrun but knows there's already an 8-lb. reduction and calcuates that will be sufficient to stop short of the target, or reduce the train to correct speed before the entrance to a speed restriction, then it will be satisfied.
As far as system overrides by the engineer, it is possible for the engineer to turn off the PTC system using a sealed switch, otherwise, without such a switch, there's no way to move a train or locomotive that has entered into certain failure modes.
As far as system overrides by the train dispatcher, not possible and not desirable. However, users can configure the system to allow a train dispatcher to run a train at restricted speed in close proximity to another train. In that case the system can be configured to enforce at whatever maximum speed is chosen by the railway, e.g., 5 mph or 3 mph or 20 mph. There can still be a low-speed collision, of course, but the likelihood of serious casualty is small.
A point made earlier that I didn't respond to previously is that "PTC knows where the rear of the train is." Well, sort of. It can look at the length on the trainsheet. But I don't think anyone is going to install GPS-equipped FREDS that talk to the system and provide greater precision. Instead, the system will be configured to be "trainsheet length plus X tolerance."
One of the other knotty problems of PTC implementation is the requirement for trainsheet updates and accuracy to be much more reliable than at present, and done in real time too. Otherwise the braking algorithms and length are going to be off. Not that hard at initial terminal, but the long local that picks up and sets out all night long? -- well, that's going to be interesting to figure out how to make all those updates into the PTC system in real time quickly, efficiently, and accurately.
Enforcement is a better term for what I meant than override. Override does connote action by a human.
I would think that GPS equipped EOT's would be desireable, and fairly cost effective. Not that better records regarding train length are a bad thing (and they should certainly factor in), but GPS in the EOT gives a relatively exact location of the rear of the train, not just estimated length with a finagle factor.
Railway Man [snipped] All of this stuff has difficult timing sensitivities. It's not like a retail store or an airline, where every day the whole operation stops dead, everyone runs around putting things right, and all the databases can be updated with the day's events and the next day, we turn the system back on, and start afresh. We can't stop the railway every night, so this all has to be done in real time but it cannot have huge effects on operating efficiency and cost. The real problem with PTC is not the technology. That part is reasonably straightforward. The problem is managing the system updates in a way that is both effective and efficient. RWM
After thinking about the para quoted above last night, and reading the above posts about updating the frequently-changing length of a local freight train, and the "real-time" adjustment of the braking calculation algorithm to better reflect actual experience, it occurs to me that the Army's IVIS system is a better parallel or example of such a system than retail stores or airlines. It's not that I'm enamored of all things military - but that system also has to run 24 x 7 nominally. Then again, a lot of the armored forces prefer to operate at night, so the data stream may drop off considerably during daylight hours. Also, the military seemingly doesn't have the same hardly any concerns about cost, though it would care about efficiency and timeliness of the updates and their possible degrading or unfulfilled effects on readiness and capability, etc.
- PDN.
Railway Man Murphy Siding Railway Man Let me repeat: There is no need to ride the territory to log and enter "safe braking distances" and in fact that is a terrible idea. The computer knows the train weight, and it knows the vertical profile, which makes it a simple calculation to determine maximum speed for the train when it is at any given point and still be able to stop short of a target. The computer displays the speed in the cab, and enforces if it is exceeded. RWM Will/can the computer allow for changes in track conditions? The only one I can think of, off the top of my head, is wet leaves on the track, or something similar that would affect braking. Is something like that even an issue? That's an astute question. Standard braking algorithms such as what we use for signal spacing assume worst-case conditions. But in the real world, rarely do trains actually brake as badly as the standard algorithm. However, the computer doesn't know that. It knows only what a worst-case scenario is, and since it's programmed to choose the safest course possible, it will choose a worst-case scenario. Thus, if the standard algorithm is instituted as the best-case condition (instead of relying upon the engineer's judgment as actually happens in the real world today), then the track capacity loss becomes rather significant. Trains end up running much more slowly and further apart then they do today. Accordingly, there's a lot of research work ongoing into devising ways to measure a train's actual response curve along with local conditions (e.g., wet rail, presence of flange lubricators, rail head profile shape, etc.), with the goal of making braking curves more like what a good hoghead would use. The TTCI is doing some good work on this right now. RWM
Murphy Siding Railway Man Let me repeat: There is no need to ride the territory to log and enter "safe braking distances" and in fact that is a terrible idea. The computer knows the train weight, and it knows the vertical profile, which makes it a simple calculation to determine maximum speed for the train when it is at any given point and still be able to stop short of a target. The computer displays the speed in the cab, and enforces if it is exceeded. RWM Will/can the computer allow for changes in track conditions? The only one I can think of, off the top of my head, is wet leaves on the track, or something similar that would affect braking. Is something like that even an issue?
Previous discussion of PTC coping with the "effect of wet leaves on rails changing the braking characteristics of trains" and related topics is roughly between the 3rd post - 10-07-2008 - from the top on Page 3 of 4, and the 1st post - 10-08-2008 - at the top of Page 4 of 4, among others, of the thread "Re: Positive Train Control - Federal Legislation Pending" at:
http://cs.trains.com/trccs/forums/t/137669.aspx?PageIndex=3
http://cs.trains.com/trccs/forums/t/137669.aspx?PageIndex=4
Railway Man Paul -- the communications technology envisioned is encrypted 802.11. The "transmission" is not the problem so much as the collection, verification, and authentification of the data, and the implications one piece of data has on all the other pieces of data and on the system's operability. For example, suppose a new industry turnout is to be cut into the main track one day. That will require:Updating the track data base with the accurate point of switch.Assigning an address to the wayside interface unitTesting and verifying the WIUUpdating the communications address database for the wayside interface unit. Deciding precisely when the WIU will start reporting to the system -- not too soon and not too late.Deciding precisely when the track database will start recognizing when the switch exists. Again, not too late (would allow an open-switch event to occur) and not too early (reaches out to poll it, can't find it, gives a system fault, trains can't be authorized over it except as stop, inspect, and proceed).Deciding when the track database is to be published to locomotive onboard memory.Making sure it happens to the locomotives that might pass over that turnout in the near future. While any locomotive might go anywhere, you can't for practical reasons update every locomotive with every change everywhere, every time it happens. Talk about bandwidth demand. Plus, all the locomotives might not be in range of an 802.11 update device very often.Getting the turnout information into the PTC system server in the dispatching office.Turning it on, at the right moment.Verifying and testing every step of the process.Running the system management checks to make sure it all works -- testing in real time on an operable system.All of this stuff has difficult timing sensitivities. It's not like a retail store or an airline, where every day the whole operation stops dead, everyone runs around putting things right, and all the databases can be updated with the day's events and the next day, we turn the system back on, and start afresh. We can't stop the railway every night, so this all has to be done in real time but it cannot have huge effects on operating efficiency and cost. The real problem with PTC is not the technology. That part is reasonably straightforward. The problem is managing the system updates in a way that is both effective and efficient.RWM
Sounds like a classic database management problem, where "management" refers to the process of managing the database as opposed to a piece of software. The IT press has lots of horror stories of mismanaged databases, one recent example of parents of a recently deceased daughter getting a nastygram from the daughter's former school saying that her attendance needs to improve.
I do have a couple of comments - the standard encryption protocols for 802.11 have been embarrassingly easy to crack. Having said that, it isn't so much that the update data needs to be kept secret (with the possible exception of how the WIU authenticates itself to the system) as that the update data needs to be authenticated to the locomotives PTC unit. One way to authenticate is to hash the data (e.g. using SHA-256), encrypting the hash with a private key from a public key protocol - on the receiving end, the hash of the received data is compared to the decrypted hash.
- Erik
erikemI do have a couple of comments - the standard encryption protocols for 802.11 have been embarrassingly easy to crack. Having said that, it isn't so much that the update data needs to be kept secret (with the possible exception of how the WIU authenticates itself to the system) as that the update data needs to be authenticated to the locomotives PTC unit. One way to authenticate is to hash the data (e.g. using SHA-256), encrypting the hash with a private key from a public key protocol - on the receiving end, the hash of the received data is compared to the decrypted hash.- Erik
I am not a communications expert nor make any attempt to understand anything beyond the basic architecture. There are large groups who do that. My notes from a recent meeting say "SHA-1 HMAC will be used for all secure messages."
Normal 0 false false false MicrosoftInternetExplorer4
I was really only talking about signal aspects when it comes to standardization for promoting safety. Amtrak engineers spend a large amount of time on foreign rails. You can't rely on people. Even if they're qualified on all the roads they operate on, there will always be the quiet and subtle danger of mindset.
Speaking of infrastructure, someone also mentioned 802.11 and that it's easy to crack. This has not been true for years, and the signal systems would be only using it as a communications medium--the actual signal system messages would have their own application-level protection in addition to whatever the 802.11 provides, so that argument is not relevant.
aegrotatioI was really only talking about signal aspects when it comes to standardization for promoting safety. Amtrak engineers spend a large amount of time on foreign rails. You can't rely on people. Even if they're qualified on all the roads they operate on, there will always be the quiet and subtle danger of mindset.
Yes and no. First, signaling systems are not train-control systems, a distinction that might seem semantic but is not. PTC is not a signaling system, it is a train-control system. Signals transmit information, they do not control trains. There is no signal system message as an integral part of the PTC system (at least on the Wabtec platform; the ACSES is a different animal) excepting that the signal system at least until the PTC system is stand-alone has to be robust in its own right, just as it is now.
The communications requirements of PTC are complex. The 802.11 messages are integral to the PTC system and the authentication and reliability of that communication link is mission-critical. The 802.11 is how the software itself (and its updates) and the track database (and its updates) gets to the locomotive platform. The locomotive platform becomes the enforcing apparatus. Not a central computer. All the server does is tell the locomotive the limits of where it is authorized to go (and any temporary reductions in speed); it's up to the locomotive to determine where it's boundaries are. Bad data? Bad results.
PTC uses existing signal systems as data input sources. It ultimately throws away the signals as unnecessary.
Railway ManPTC uses existing signal systems as data input sources. It ultimately throws away the signals as unnecessary.
That particular line is dark, but in the case of the Watertown, NY runaways if the cars had "departed" overnight instead of in the middle of the morning, they would have travelled some 8-10 miles without the benefit of a locomotive, EOT, or even human detection, and might well have been lying in wait for the next train up the line, unnoticed. PTC would not know they were there unless they were picked up by a track circuit.
tree68Railway ManPTC uses existing signal systems as data input sources. It ultimately throws away the signals as unnecessary. Are not the signal systems part of the important data? Existing signal systems not only indicate track occupancy, but track integrity, and in many cases are connected to such things as slide alarms (rock slides). That particular line is dark, but in the case of the Watertown, NY runaways if the cars had "departed" overnight instead of in the middle of the morning, they would have travelled some 8-10 miles without the benefit of a locomotive, EOT, or even human detection, and might well have been lying in wait for the next train up the line, unnoticed. PTC would not know they were there unless they were picked up by a track circuit.
Separate into pieces, and examine the pieces. Are any of these pieces only capable of being handled by an ABS system:
ABS is a means of conveying information about track conditions ahead. The information it conveys are occupancies, broken rails, tripped detectors, and open switches. Train occupancies with PTC will be picked up by the train itself; the broken rail by audio overlays, and the open switches and derails by WIUs. The only piece of the ABS system that might have continued value, for awhile, is broken-rail protection. You can go through the cases and rip out everything but the track circuit itself. Almost everything else has to get a WIU anyway.
CTC is an overlay on ABS that provides a means of transmitting authorities. It additionally is interfaced with power-operated switch machines. There's no unique value here, and everything the CTC does, the PTC does. The power-operated switch machines remain, but a DTMF-style audio-overlay circuit can provide the route locking feature.
zugmann petitnjWhat is their problem? NTSB just nailed them to the wall for having multiple signalling systems. It that not enough of a warning? Or is the multimillions of law suits that follow cause them to make things consistent. This is not a hard problem. Upgrade all the signal systems so that yellow over red means the same in every system. One answer: cost. It would take billions to standardize everything. Billions that an be better spent (IMO) elsewhere. On all my territory yellow over red means approach (unless its a dwarf, then its a slow approach). If I ran somewhere where it meant different, then I guess I'd have to learn it. That's the definition of being qualified.
IT would save Millions in the future by keeping one standard operation. We all know in the initial investment is going to be a huge chunk of $$. It the same theory of the Speed train from city to city. THe initial investment is going to huge but in the long-term is going to save more $$
Railway Man aegrotatio I was really only talking about signal aspects when it comes to standardization for promoting safety. Amtrak engineers spend a large amount of time on foreign rails. You can't rely on people. Even if they're qualified on all the roads they operate on, there will always be the quiet and subtle danger of mindset. But we do rely upon people -- the pilot not to fly the plane into the ground on final, the paramedic to read the label on the IV bag correctly, the driver of the car behind you to see your brake lights. And people design the safety systems. As illustration, William Langewiche's article on the GOL 738/Embraer Legacy collision in Vanity Fair -- a collision with numerous human single-point failures as well as a very complex safety system that performed in unanticipated ways. [rest snipped; emphasis added - PDN]
aegrotatio I was really only talking about signal aspects when it comes to standardization for promoting safety. Amtrak engineers spend a large amount of time on foreign rails. You can't rely on people. Even if they're qualified on all the roads they operate on, there will always be the quiet and subtle danger of mindset.
But we do rely upon people -- the pilot not to fly the plane into the ground on final, the paramedic to read the label on the IV bag correctly, the driver of the car behind you to see your brake lights. And people design the safety systems. As illustration, William Langewiche's article on the GOL 738/Embraer Legacy collision in Vanity Fair -- a collision with numerous human single-point failures as well as a very complex safety system that performed in unanticipated ways.
[rest snipped; emphasis added - PDN]
"The Devil at 37,000 Feet" by William Langewiesche, January 2009, can be found at:
http://www.vanityfair.com/magazine/2009/01/air_crash200901?currentPage=1
It's 8 pretty long web pages - looks interesting. Thanks for sharing the reference. (If you go to read it, try to concentrate on the article and not the rather nice photos of model Gisele Bundchen in the margins - compensation of sorts for having to follow the technical stuff.)
EDIT - add, since my previous version was inadvertently deleted:
Thanks for referencing this - VF is not on my regular reading list.
This article is about the much-publicized Sept. 29, 2006 mid-air collision over the Brazilian Amazon jungle of a private jet on its maiden flight to the U.S. with 2 American pilots, and a 2-week old Brazilian commercial airliner with 150+ people onboard who all died - both esssentially brand-new aircraft.
Good example of what can go wrong . . . go wrong . . . go wrong . . . with people, their systems, and the machines. The author is not very nice to the EDIT: avionics aeronautics designers - particularly the man-machine interface. For those of us who have to manage and worry about that kind of thing, it's troublesome. Notably, the Brazilian airliner pilots did nothing wrong as far as I can see, and yet they were the ones who died. One thing I didn't see addressed was if either of the 2 American pilots had military experience ? They didn't seem to have much in the way of that 6th sense of "situational awareness" going on. And the "check-out" procedure seemed like it was pretty lax for them to be flying such a sophisticated and elaborate piece of equipment - not like anyone could just climb in and fly it. Good reading - just not before you fly anyplace. I'll not spoil the plot of RWM's point about how one of the safety systems that performed in an unanticpated way - that's just chilling, when you think about it.
Head-in-the-cockpit syndrome, lost in the intracacies of managing the electronics.
That thought lept to my mind the first day I saw PTC demonstrated to me in service, in the cab of a locomotive, in 2004. Should the engineer be looking out the window or staring at a flat-screen monitor? We were all staring at the screen waiting for it to tell us what to do next. I didn't like that. This still deeply concerns me. I have been striving ever since to simplify, simplify, simplify, the machine, so that the people can do their job without becoming overwhelmed by the complexity of the machine. Same goes for the dispatching console. It's turned into a flashing jukebox of crap laid out by people who have absolutely zero sense of graphics, clarity, readibility, functionality, and efficiency. Why? Because they don't actually use it. Worse, they employ user review groups who consist of cherry-picked people who will deliver the "right" answer instead of the honest answer. The stuff works but it's about as awful as you can get.
As example of the problems that encouraging a machine to do too much creates, I just spent 30 minutes answering a very simple question: "What happens when a locomotive can't ping its GPS satellite, and it's stationary?" It's not a simple answer -- it took me 1,000 words just to outline the basic outcomes. The short answer is: It doesn't result in a safety fault, but it can eventually bring the subdivision to a grinding halt. The brute-force solution is to recognize this possibility at every location where it could occur, and pre-plan for it with electronic workarounds. The better solution by far is to simplify the machine so that it doesn't need to know so much data so often so accurately.
Engineers and marketers, as Langweische pointed out, can fall in love with their products and enable them to do everything, just in case someone might want it someday. One of my jobs right now is to figure out how many PTC features we can strip out, how many options we can turn off, and still make it work and meet the law. The last PTC system I worked on, by the time I was done, I had turned off more than 95% of the features and options originally offered by the engineers. That made me very happy!
Paul, you pointed out earlier that the problem is the machine can break. A.C. Clarke was wrong. The machines work fine, right within specs. The problem is that the machine is so complex no one ever figures out why it does anything! Have you ever figured out all the features on your cell phone? Windows computer? DVD Player? ipod? Microwave oven? How about the toaster? Nope! My daughter gave me an iPod for Christmas and I still hate the stupid thing. (I want to register a website, thisstuffsucks.com. I will list on it everything ever made or operated by Microsoft, Apple, Chrysler, AT&T, Verizon, Sprint, Comcast, Epson, H-P, Palm, Blackberry, and Kodak.) You just figure out barely enough to make it sort-of work, and when it does or doesn't do what you hope it will do, you're baffled. That is precisely what Langweische was getting at: systems that no user can ever figure out why or what it's doing, and when things go wrong, no one even knows they have gone wrong.
Langweische is my favorite author, by far. No one else gets the technical details as right, explains them as clearly, or turns a phrase so eloquently. If the last paragraph in the "Devil at 37,000 feet" article doesn't make you shiver, you might be dead from the neck up. Patrick Smith, the "Ask the Pilot" columnist and a 767 captain, said that Langweische made exactly one technical mistake in the "Devil" article, a very minor one, misnaming a control center, which might have been a spellcheck error in fact. That's as impressive a recommendation as you can get.
RWM: I love your avatar. I'm thinking that must be in Texas somewhere.
RWM:Add to the list digital cameras. I purchased a Pentax 35mm without a built in light meter back in 75 and loved it. With the digital D40, it comes down to point and shoot (which works quite well, but I havent taken the time). My Blackberry is the same, I answer the phone, retrieve email, but most of the features are not used.
Now it is time to read the aforementioned Vanity Fair article.
Ed
spokyoneRWM: I love your avatar. I'm thinking that must be in Texas somewhere.
Beats me! I lifted it off an email of funny signs someone sent me awhile ago.
Van Horn, Texas, and no, you really, really don't want to eat there, ever....
23 17 46 11
That was a chilling article. Well worth the hour of time invested. Have we become a slave to technology? At times.
Railroads have a very good safety feature regarding this type of situation. It is called a "pilot"engineer. The two pilots had very little experience with the territory, language, and the plane. Add technology that precise and the arrows did in fact collide.
I am reminded of a conversation in a telescope retail store. An amatuer astronomer engaged in a conversation with two others that were drooling over the latest 10 inch mak with autofind features, enabling them to program in any of 10,000 (or more deep sky objects). The one asked the two "what do you use that for?" The intent of the question was to inquire as to a specific use for galaxies, open clusters, globular clusters, nebulas, doubles, etc.
The two answered in a very patronizing tone it was used to look at far away objects, which could easily be programed into the computer system. At that time the owner walked in, saw the single astronomer and declared "oh my god, where have you been? I have told people about you and they dont believe that someone can actually use a ETX90 on a card table with only charts to find deep sky objects."
The look on the faces of the two astronomers was priceless. They bought into the technology without understanding the basics (and the beauty) of finding your way to the right place in the sky.
Technology can become a distraction and a very dangerous one at that.
Thanks for the link to the article.
edblysardVan Horn, Texas, and no, you really, really don't want to eat there, ever....
Now this is irony. I have been to Van Horn, Texas, quite a few times. And eaten at various places there. I wonder if this was one of them?
You would remember this one...ever have to wring the grease out of a Whataburger?
The chicken there drips the stuff....and you can't taste the difference between the chicken and the fries...
edblysard You would remember this one...ever have to wring the grease out of a Whataburger? The chicken there drips the stuff....and you can't taste the difference between the chicken and the fries...
Would you like some chicken and fries with your grease?
That's unusual?? For West Texas?? It would taste funny if it was not like that!
In the dark, rain, or after 12 hours on duty, they all tend to look pretty much the same . . .
Especially when you combine all three.....
A lot of "meat" to respond to here, so here goes:
Railway Man Head-in-the-cockpit syndrome, lost in the intracacies of managing the electronics. That thought lept to my mind the first day I saw PTC demonstrated to me in service, in the cab of a locomotive, in 2004. Should the engineer be looking out the window or staring at a flat-screen monitor? We were all staring at the screen waiting for it to tell us what to do next. I didn't like that. This still deeply concerns me. I have been striving ever since to simplify, simplify, simplify, the machine, so that the people can do their job without becoming overwhelmed by the complexity of the machine. Same goes for the dispatching console. It's turned into a flashing jukebox of crap laid out by people who have absolutely zero sense of graphics, clarity, readibility, functionality, and efficiency. Why? Because they don't actually use it. Worse, they employ user review groups who consist of cherry-picked people who will deliver the "right" answer instead of the honest answer. The stuff works but it's about as awful as you can get.
Yup - good for you and your instincts ! I've read this same criticism about high-end cars - specifically, BMWs and the Japanese imports. I'm convinced that none of this stuff should be designed by manufacturers alone - the design team must include a user from the real-world, who has absolute veto power and is not afraid to yell "That's nonsense !" (or one of the less-acceptable synonyms).
Twenty years ago when I got back into the consulting business one of my first surprises - in the context of stormwater management calculations - was how much time we had to spend on "outsmarting the computer" so that we could take the data we had, input it in the format that the specialized application program demanded, and get results that were 1) correct, verifiable, and defensible, 2) understandable, and 3) presentable to reviewers, etc. That specialty is much better now - but we're still having to play that game with surveying and drafting software (AutoCAD and Eaglepoint, take notice).
When I took the applied engineering course on "Numerical Methods" (computer calculations of odd functions like logarithms, exponentials, modeling, systems, sytems that are modeled by differential equations and/ or integrals, etc.) we spent a lot of time learning how to recognize and quantify uncertaintly and the bounds ("limits") on the possible range of errors, and the better ways / sequences to calculate certain things so that the results weren't containing too much of the uncertainty or "noise" from the data. Every once in a while since then I run into a anomalous result that is caused by one of those poorly-chosen methods (including a hydraulic channel and depth "backwater" calculation program used for floodplain management).
Of course, recall some of the more famous "number busts" of recent memory - the miles vs. kilometer input goof to one of the outer space (or Mars ?) probes, the grinding of the mirrors for the Hubble telescope, the evidently mis-entered navigation data for the Korean airliner (KAL 700 ?) that was shot down by the Russians over the Kamchatka Peninsula in the 1980s, the lbs. vs. kilograms fuel load into the 747 "Gimli Glider" in Canada about a decade ago, and I'm sure many, many, more.
For a long time I had way more time in the right seat of 4 small private aviation aircraft (all different owners - mostly Cessna 172 N7019Q) - than in commercial airliners. The pilot I flew with most was VFR exclusively - to get certified/ rated on IFR would take too much time away from business for him and the airplane. For him, simple was better. Another plane was essentially a flying test bed for avionics (by Narco - I'm dating myself here) that were worth about 3 times what the plane was, but we were able to transit NY Control in heavy fog with no problems. So I've seen both sides of this.
There was a low-speed collision of 2 commuter trains on the Hatboro-Warminster line of SEPTA a couple years ago - the NTSB (or FRA) report on it reads a lot like the railroad version of this aircraft article: newbie operator ran thru a couple red signals and a switch, but the DS didn't notice because the audible alarm function was turned off (because it was always going off), and didn't notice the flashing icon at the bottom of the screen, if I recall correctly. (The other engineer noticed the signal drop to red unexpectedly, stopped her train, figured out what was happening, and was asking for permission to reverse when the impact came, I believe.)
Again I attempt to quote from Robert Townsend in Up the Organization!: "Man is a complicating animal. He simplifies only under extreme pressure. But when you force him, he will, and then will be privately amazed at how good the solution is." (or similar) He also has a lot of similar points to make under the heading of "Computers (and their Priests)" - this is from back in the 1960s, mind you - the key points of which are: 1) If the operation doesn't have its act together on paper, all the computer is going to do is speed up the mess; 2) Companies have gone bankrupt from computerizing too fast; and 3) The systems people love to invent reports and functions that no one has asked for or needs. To anybody who is reading this far - I highly recommend that you get a copy of this book (paperback, under $10). I've also come to know that there are some odd senses of humor in the participants here, and Townsend's book will probably appeal to that part of your personalities as well. (In the addendum to the revised version, he complains about how GE and its executives got off too lightly when convicted of selling defective jet engine parts - and then were able to deduct the fine for same. As he said: "We don't need to worry about the Russians destroying us - we've perfected 'do-it-yourself' methods !")
True.
What do we really need PTC to do - and nothing more ? (at least initially) 1) Enforce authority = limits of operation permitted for a specific train; and 2) Maximum speeds. Necessarily, it must be able to 3) Stop the train for the 1st, and/ or slow it down for the 2nd, which means it must be able to handle the braking function. That has to be scaled realisticly to avoid clogging the line with false apparent "violations". Other than that, I think that anything else is jewelry and nice-to-have but not needed "options" - like with new cars.
Paul, you pointed out earlier that the problem is the machine can break. A.C. Clarke was wrong.
No, Arthur C. Clarke was still right, if we're thinking of the same quote: "Any sufficiently advanced technology is indistinguishable from magic." He didn't say that it had to be good magic - it could equally well be bad magic. The Caiap/o Indians and their shaman in Brazil would understand that, I think.
The machines work fine, right within specs. The problem is that the machine is so complex no one ever figures out why it does anything! Have you ever figured out all the features on your cell phone? Windows computer? DVD Player? ipod? Microwave oven? How about the toaster? Nope! My daughter gave me an iPod for Christmas and I still hate the stupid thing. (I want to register a website, thisstuffsucks.com. I will list on it everything ever made or operated by Microsoft, Apple, Chrysler, AT&T, Verizon, Sprint, Comcast, Epson, H-P, Palm, Blackberry, and Kodak.) You just figure out barely enough to make it sort-of work, and when it does or doesn't do what you hope it will do, you're baffled. That is precisely what Langweische was getting at: systems that no user can ever figure out why or what it's doing, and when things go wrong, no one even knows they have gone wrong.
ROFLMAO last night when I read that! And now my wife wants to meet you, too ! She can't believe a "railroad nut" (nerd) would think that way - but she agrees completely.
A lot of Tom Clancy's plot devices in his novels revolved around faking out or spoofing computers and their sensors or users.
mudchicken will likely agree with this one: I've yet to meet a surveyor who likes the 1990's HP-48 series "pocket calculator" better than the 1980's HP-41 series it replaced - it's a "do-everything" programmable, but it's too complicated for everyday work. The astronauts used the HP-41 to go to the moon - wasn't that good enough ? Per my point above, the HP-41's plug-in pre-programmed modules for specific profession's applications were developed with input from those professions, so they were pretty intuitive and popular, unlike the HP-48. As a result of all that complexity, the HP-48 is demonstrably slower at simple, everyday tasks - like arithmetical adding and division - than the HP-41, 'cause it has to go through all that logic for even basic functions. (Actually, I'd be OK with going back to the 1970's HP-45 for a lot of work - but that's just me.)
Too bad your idea for www.thisstuffsucks.com is already taken and apparently has been since 2007 (copyright date). It's now 10 recent pages and 436 archived pages of single-spaced subjects. Though not limited to electronic gizmos - it seems to include rants about various aspects of society and life itself, for example - nevertheless a lot of it tracks your idea, so evidently there's a lot of validity and felt need there. Think up a different dot-com name and get going on your path to fame and fortune !
Langweische is my favorite author, by far. No one else gets the technical details as right, explains them as clearly, or turns a phrase so eloquently. If the last paragraph in the "Devil at 37,000 feet" article doesn't make you shiver, you might be dead from the neck up. Patrick Smith, the "Ask the Pilot" columnist and a 767 captain, said that Langweische made exactly one technical mistake in the "Devil" article, a very minor one, misnaming a control center, which might have been a spellcheck error in fact. That's as impressive a recommendation as you can get. RWM
Again, thanks for the references - I need somebody new to read. I see from his bio on the Vanity Fair website that he was formerly a professional pilot, so that undoubtedly has a lot to do with the factual accuracy, and the attention (obsession ? they're not all bad, you know) to same.
edblysardYou would remember this one...ever have to wring the grease out of a Whataburger? The chicken there drips the stuff....and you can't taste the difference between the chicken and the fries...
Reminds me of a restaurant in West Quincy, MO, that featured catfish. No matter what you ordered, it tasted of catfish, especially anything that was fried. I had a greaseburger. Shoulda just had the catfish, because that's what the burger and fries tasted like!
Sounds like the Van Horn place changes it's fry oil about as often as the railroads change the oil in a locomotive.
Yeah, well, down here, if you can deep fry it, someone will eat it...
Lard is one of the major food groups, right?
edblysard Yeah, well, down here, if you can deep fry it, someone will eat it... Lard is one of the major food groups, right?
I think they have a franchise in Walsh, CO (CVRR) called Lucy's Hog Trough (real place)....
I just finished reading Langewieche's article on Somolian piracy (also in VF) and would highly recommend it.
He is an excellent writer and appears to have featured articles in VF on a regular basis. I havent read VF in several years...it got a bit nasty for my tastes, but their editorial content was always well written.
At $1 an issue, I might subscribe again. Nice cover shot for May.
MP173I just finished reading Langewieche's article on Somolian piracy (also in VF) and would highly recommend it. He is an excellent writer and appears to have featured articles in VF on a regular basis. I havent read VF in several years...it got a bit nasty for my tastes, but their editorial content was always well written. At $1 an issue, I might subscribe again. Nice cover shot for May. ed
When it's free on the website, why bother paying!
Langewische previously wrote for The Atlantic -- archives also free online -- where he specialized in ocean shipping and nuclear weapons proliferation. He authored the book "Outlaw Sea" which is based on his work at Atlantic, and is must-read to understand the ocean shipping business, and the manner in which business has learned to evade regulation and operate in an extra-legal environment, and ocean trade. While at Atlantic, James Fallows work on China has done more for me to understand that aspect of business than anything I know of.
Paul_D_North_Jrmudchicken will likely agree with this one: I've yet to meet a surveyor who likes the 1990's HP-48 series "pocket calculator" better than the 1980's HP-41 series it replaced - it's a "do-everything" programmable, but it's too complicated for everyday work. The astronauts used the HP-41 to go to the moon - wasn't that good enough ? Per my point above, the HP-41's plug-in pre-programmed modules for specific profession's applications were developed with input from those professions, so they were pretty intuitive and popular, unlike the HP-48. As a result of all that complexity, the HP-48 is demonstrably slower at simple, everyday tasks - like arithmetical adding and division - than the HP-41, 'cause it has to go through all that logic for even basic functions. (Actually, I'd be OK with going back to the 1970's HP-45 for a lot of work - but that's just me.)
Paul,
Lessee, the last manned moon mission was December 1972 (at the end of my first quarter at Bezerkeley) and I first read about the HP-35 in "Mac's Service Shop" page in the March (?) 1972 issue of Popular Electronics. Got my HP-45 in December 1973 and only stopped using it about 6 years ago after downloading a program called "grpn" (which has a resistors in parallel command that works with complex numbers - latest maintainer works for Analog Devices).
Then again, I find having to push the "talk" button on wireless phones annoying, phones are supposed to go "off-hook" when picked off the hook...
On a related note, "Robert X Cringely" had a recent article on the 30th anniversary of Three Mile Island, where he pinned most of the blame on really poor user interface design and poor operator training. One problem was that there were seven hundred warning messages being printed out before the critical one warning about dropping water levels in the reactor vessel.
Paul_D_North_Jr Then again, I find having to push the "talk" button on wireless phones annoying, phones are supposed to go "off-hook" when picked off the hook...
Reminds me of a few years ago, when our retired pastor (who was about 80 at the time) surprised everybody by finally getting a cellphone. Of course, the kids (anyone under 30, as far as I'm concerned) had to check out the phone and all it's options. "Did you know you can do this?" "Did you know you could do that?" was answered with, "No, I just need to pick it up and dial." One of them triumphantly pointed out he could program the phone recognize his voice so he wouldn't even have to do that much. He could just talk into the phone and tell it who he wanted to talk to and it would connect him-how advanced was that?
Pastor just chuckled and said, "In my day, that's how all the phones worked."
A.K. CummingsGreyhound — The political mandate has nothing to do with efficiency, and everything to do with public outcry. When people die in a preventable accident, you'll always have a government response because that's what people demand. There may be times when that goes overboard, but personally, I think it's generally a good thing. The public reaction to Upton Sinclair's "The Jungle" led the government to legislate safer food. Public reaction to Ralph Nader's "Unsafe at any speed" led the government to legislate safer cars. The list could go on ad infinitum. And generally speaking, these are good things. My opinion: The public has a stake in the rail system as passengers and as people who live beside rail lines. They deserve a seat at the table. Burlington Northern had a great deal of success experimenting with PTC back in the early 1990s. Our columnist Don Phillips was present for a demonstration of it, and was amazed at what it was able to do. I'm with you guys: It will take time and money, but the industry will find a way to implement it. Finally, as to cost, media reports indicate the cost of lawsuits alone in the Chatsworth crash could exceed $1 billion. When you calculate the efficiency of PTC, you have to include the money saved by accidents that are prevented — and I don't think there's any doubt that PTC will prevent accidents. The problem with accident prevention is that you really won't know overall when PTC has prevented a crash between a commuter train and a freight train or saved a tank car of chlorine gas from getting punctured and poisoning a community. Even if you could figure that out, you'll never know how much money was saved. However, that's not the same as saying $0 was saved. Best, Andy Cummings Associate Editor TRAINS Magazine Waukesha, Wis.
Well, If your columnist Don Phillips was present for a demonstration of it, and was amazed at what it was able to do, I guess that settles it. But then, Phillips is also aparently amazed by France so there still may be some questions here. He never saw a government power grab that he didn't like.
Seriously, the safety issue with PTC is a red herring. You can't just throw billions of dollars at a system and justify it by simply saying it will improve safety. Which is what you're doing here. If safety was an abolute goal to be pursued at the expense of everything else, trains and motor vehicles would operate at 25 MPH maximum. That would improve safety, but the cost would be prohibitive. So we drive and operate trains well above 25 MPH knowing full well that in doing so we are reducing overall costs at the expense of safety. I'm not saying safety isn't critically important. It is. What I am saying is that you can't use it to justify any expenditure, any time and any place.
PTC's projected impact on safety will be negligible. The US rail system is operated in a very safe manner. You cite $1 Billion from the Chatsworth crash as support for the need for PTC. Well, one such crash per year wouldn't pay the capital costs of a $15 billion PTC system. And fortunately, such disasters are few and far between. The cause of the Chatsworth crash is being laid on misconduct by the passenger train's engineer. Spending vast amounts of scarce resouces in reponse to very rare cases of misconduct is a waste and should not be toleraed.
Projections posted by RWM are that PTC will reduce capacity on the busiest rail routes. This should give anyone pause. You aparently do not pause. Reducing this capacity can only result in increased costs to the economy as a whole. This will divert resources from other safety projects. It has to. We can't spend the resource twice and if it is wasted on a government mandated system that results in negligible gain then other, more productive, uses of the resources must be neglected. Doing everything to achieve Utopia is not an option.
I have raised legitimate questions about the government commanded introduction of an unproved system. You resonded by citing Upton Sinclair, Ralph Nader, and Don Phillips. You did not address any of the questions. You're in love with an ideology of Utopia, just as Phillips is in love with France. Niether one works all that well.
Wel here is my 2 cents I am a qualified locomotive engineer and I work to Chicago I can operate on the CN/IC, BRC, CSX, IHB and every now and then the EJ&E I carry the cora book for the Chicago area which has the signals for all of the above railroads that I can operate on. Railroads are slowly using the same signal system but it cost money a lot of money that the railroads would rather spend on the track. Here is the way that I see the color aspect on the signals green we go, yellow we slow and red we stop problem solved.
Rodney
Rodney Beck....Here is the way that I see the color aspect on the signals green we go, yellow we slow and red we stop problem solved. Rodney
The Chatsworth crash would have been prevented. The Pere Marquette would have been a slow speed crash at worst. That signal would have sent a 15mph limit.
spokyoneRodney Beck....Here is the way that I see the color aspect on the signals green we go, yellow we slow and red we stop problem solved. Rodney Could PTC be just that simple? The signal aspect is transmitted to an approaching train. Yellow commands the engineer to reduce speed to a preset value. That value need not be the same for every signal, but would be the same for every train passing that location. Approaching a red would apply the brakes if the engineer has not already done so. An in-cab audio warning would alert the crew to a PTC intervention. The Chatsworth crash would have been prevented. The Pere Marquette would have been a slow speed crash at worst. That signal would have sent a 15mph limit.
Spokyone, what you are describing is Automatic Train Control (ATC), which has been around since the 1920s and does some of what PTC does, but badly, and worse it costs much more! Recent ATC installations have cost more than $1-2 million per mile just for the wayside equipment, which if extended over the national network that PTC will cover would cost $25 billion for the wayside plus another $4-5 billion for the locomotive hardware.
Moreover, ATC can't do a lot of things that PTC will do, except with expensive, complicated, ad hoc, inflexible, inefficient, and capacity-robbing workarounds:
I can make an ATC system do all of these things listed above, but no one will like the price tag or the harm it does to railway capacity.
ATC is state-of-the-art for 1925. It didn't work so hot then, it was terribly expensive, and little has improved. There are "modern" ATC systems out there on the market but it's sure a bad way to do things in my opinion.
We've been working on PTC for 30 years. We're not overlooking the obvious. We can debate the cost-benefit ratio, but the technical solution was figured out over a decade ago. That decision has been made, finis, as far as the Class 1 railway industry in this country is concerned.
Spokyone, what you are describing is Automatic Train Control (ATC),
Recent ATC installations have cost more than $1-2 million per mile just for the wayside equipment, which if extended over the national network that PTC will cover would cost $25 billion for the wayside plus another $4-5 billion for the locomotive hardware.
8. It cannot be installed without creating enormous problems with trade-crossing signaling because of frequency conflicts, which means several billion more to redo thousands of grade-crossing predictors.
Thank you
spokyoneI had been thinking it would be just an upgrade from CTC with bi-directional communication between the lead locomotive & the signal. The locomotive expense would be similar with PTC & ATC.
Unfortunately to install cab signals (which is what ATC is a flavor of) pretty much mandates building a whole new CTC system in many cases. Also a great deal of the PTC is going in dark or ABS territory where cab signals would require all-new signaling and PTC does not require any at all. The locomotive expense is higher with ATC than PTC because the ATC requires a lot of fussing around with the pickup shoe, and solving current and frequency isolation issues. PTC is just some boxes on a rack and some antennas on the roof. Not hard to install, and very little calibration required.
I thought grade crossing signals were completly separate & autonomous.
Unfortunately no -- not when cab signals are involved (which is what ATC is). Cab signals work using frequencies in the rail. So do grade-crossing signals. Each cab signal aspect or speed instruction requires a unique frequency broadcast down the rail. The box in the locomotive sees, say, 86 Hz, and says, "ah ha, I'm supposed to be proceeding at 30 mph and diverge at the next control point." Each grade-crossing approach circuit also requires a frequency on the rail, and they have to be unique from each other if they overlap, and on a line running at 79 mph passenger, 70 mph freight, grade crossings within 8,000-11,000 feet of each other will overlap. Also the grade-crossing signals have to span control points and insulated joints which really tangles up the frequency selection process for the cab signals. Once you start on a cab signal system, you are choosing a fixed, firm set of frequencies for the entire railway system nationwide. But grade-crossing signal frequencies are not a national standard per se but a collection of local systems designed to work effectively in their own little neighborhood, because they don't have to know wha a grade crossing on the other side of the country is doing. Very quickly frequencies are used up, and frequencies that are adjacent bleed into each other which results in things that are highly undesirable such as grade-crossing signals that do not activate or unreadable cab signal aspects which knocks the train down to restricted speed. That creates severe problems which are very costly to solve, and in some cases can't be solved at all -- which results in running all the trains at very slow speeds.
This still doesn't solve all the other problems with ATC. Using ATC instead of PTC would be like me saying, "I need to buy a car to drive to my job which is 20 miles away, but maybe I should look into walking every day instead. "
Alright, let me ask a really simple question....
Where can I read a primer on PTC? Instead of asking tons of questions about it, is there a website describing what it is, etc?
Never mind, I found plenty to read (and watch on it).
RWM, when you say ATC can't enforce restricted speed, do you mean the top allowable speed (20mph for us) by rule or the changing value of restricted speed? By changing value I mean sight distance, the less distance you can see, the slower you (should) go.
Our ATC enforces restricted speed to a preset speed limit. Exceed that limit and you get a penalty service application. It doesn't address when your speed should be under that preset limit because of limited visiblity. In that regard, I would agree with you.
Jeff
jeffhergertRWM, when you say ATC can't enforce restricted speed, do you mean the top allowable speed (20mph for us) by rule or the changing value of restricted speed? By changing value I mean sight distance, the less distance you can see, the slower you (should) go. Our ATC enforces restricted speed to a preset speed limit. Exceed that limit and you get a penalty service application. It doesn't address when your speed should be under that preset limit because of limited visiblity. In that regard, I would agree with you. Jeff
That's what I meant. You stated it better than I did.
For Ed and Spokyone, here's why that's not good enough. Suppose you have a train moving on a siding toward the end of the siding, at restricted speed (20 mph), toward a signal indicating stop. The ATC code in the rail sets a maximum of 20 mph. The train obeys that limit and no enforcement is made. But instead of stopping at the signal it continues to move past it at 20 mph, . Now the ATC provides a penalty braking application. However, by the time the train gets stopped, it's already out into the single-main track in the face of an approaching train moving at 79 mph. The safety system has just failed to prevent a collision.
There are ways you can trick ATC into stopping a train short of a signal in this case, such as putting another frequency onto the rail that tells the train to stop short, but these are the equivalent of moving the signal far enough back into the siding that an overrun has sufficient braking distance to stop before fouling the main track (at the cost of shortening the siding effective length by several thousand feet but still paying for the now useless track. However, there are other scenarios (crossovers, overspeed derailments into the path of another train), that ATC can't resolve. It's not fine-grain enough control.
Railway ManFor Ed and Spokyone, here's why that's not good enough. Suppose you have a train moving on a siding toward the end of the siding, at restricted speed (20 mph), toward a signal indicating stop. The ATC code in the rail sets a maximum of 20 mph. The train obeys that limit and no enforcement is made. But instead of stopping at the signal it continues to move past it at 20 mph, . Now the ATC provides a penalty braking application. However, by the time the train gets stopped, it's already out into the single-main track in the face of an approaching train moving at 79 mph. The safety system has just failed to prevent a collision.There are ways you can trick ATC into stopping a train short of a signal in this case, such as putting another frequency onto the rail that tells the train to stop short, but these are the equivalent of moving the signal far enough back into the siding that an overrun has sufficient braking distance to stop before fouling the main track (at the cost of shortening the siding effective length by several thousand feet but still paying for the now useless track. However, there are other scenarios (crossovers, overspeed derailments into the path of another train), that ATC can't resolve. It's not fine-grain enough control.
If I'm getting this right, the ATC equivalent of PTC in your siding example would be dividing the siding up into short blocks with decreasing restrictive speed enforcement (e.g. 20, 15, 10, 5, 2.5 ...) - difference being is that the block length would adjust to expected braking performance of the train.
I'd think it would be possible to implement the equivalent function in a modified ATC system - use and audio frequency overlay to judge the distance of the train from the end of the siding, and have the ATC signal give either a continuously variable speed limit or with small speed steps. This would require replacing all of the ATC equipment on the locomotives and at least some trackside equipment - at which point PTC makes more economic sense.
A note about technology. When continuous ATC systems were first implemented, the technology for resolving the received frequency required a relatively large spacing to reliably distinguish frequencies. It is now ridiculously easy to reliably measure frequency to a fraction of a Hz (cycle per second).
erikemIf I'm getting this right, the ATC equivalent of PTC in your siding example would be dividing the siding up into short blocks with decreasing restrictive speed enforcement (e.g. 20, 15, 10, 5, 2.5 ...) - difference being is that the block length would adjust to expected braking performance of the train.I'd think it would be possible to implement the equivalent function in a modified ATC system - use and audio frequency overlay to judge the distance of the train from the end of the siding, and have the ATC signal give either a continuously variable speed limit or with small speed steps. This would require replacing all of the ATC equipment on the locomotives and at least some trackside equipment - at which point PTC makes more economic sense.A note about technology. When continuous ATC systems were first implemented, the technology for resolving the received frequency required a relatively large spacing to reliably distinguish frequencies. It is now ridiculously easy to reliably measure frequency to a fraction of a Hz (cycle per second).
The solution you describe is a lot more frequencies than are available. I think there would be great difficulty in getting it to work with "five nines" reliability without losing a lot of train speed and track capacity. I am not educated enough to explain why in a way you'll find satisfactory. The track circuits are imperfect due to varying degrees of resistance every time the weather changes. As I recall from the last installation I worked on (a couple of months ago), we had only 12 frequencies to work with. That's with the latest, greatest ATC equipment. It still is having issues with grade-crossing predictors that don't predict due to frequency conflicts and problems with all sorts of real-world misery such as rusty rail when trains don't run for a day, squishy track subgrade that is wet one day and dry the next, and so forth, and a lot of air-brake issues.
Thanks RWM. I was thinking you meant the changing values part, but wasn't sure. Even a collision when a train is running under restricted speed conditions can be deadly.
Maybe we need another thread on PTC, but I have a couple of questions.
When approaching a Form B (work zone GCOR), how will a train be cleared up? Will they contact the foreman verbally, who will then clear them verbally and enter into the system that the train can proceed at whatever speed he prescribes thru the limits? Will the process be completely digital with the engine sending, either manually or automatically, a request for instructions and the foreman responding without actually talking to the train?
The other question is, will on-track equipment and hi-rails that may not shunt the track circuit (where there is signalled track) be equipped with GPS so that the system knows when they are out of their track authority? Most of the time people think that it is only when a train overruns a Form B that accidents can happen, but we have had instances where MOW forces left their authority. One extreme case was a track inspector getting a Track and Time on one track in two MT territory, than setting on the wrong track!
RWM,
Are the 12 frequencies you've mentioned for ATC use or for audio frequency overlay?
I'd be pretty sure that a continuously variable ATC speed signal is possible (or something that has enough steps to be close enough). The tricky part would be ensuring that the ATC receiver is picking up something that can only be an ATC speed control signal - mistaking a stray signal for an ATC speed limit signal is a great recipe for disaster.
I shouldn't be surprised that audio frequency overlays can have problems in estimating distance - there are some parallels with what I'm doing at work. Another method that could work is using a magnetic sensor to detect the presence of a train within a few feet of the sensor (problem here is either doing the wiring or replacing batteries for a wireless sensor).
Anyway, it is probably cheaper to go straight to PTC than to implement a souped up ATC.
My previous post on this regarding my one concern with PTC (which hasn't been answered, somewhat to my surprise) having vanished for some reason, I'll briefly restate it: What happens when something in the system breaks? Having considerable experience with aircraft accident/incident investigation, I can assure folks that the magic does, in fact break. Not referring to bad programming (endemic) or operator error (also endemic) but just plain simply breaks.
In the present signalling system, that usually means a dark signal (stop and find out what's going on) (yes, I know, there are ways in which a signalling failure can result in a false clear, but they are pretty rare).
In general, seems to me that some form of PTC is indeed a very good thing and should, in the long run (after amortizing the money) result in better -- perhaps much better -- productivity and lower costs, and I'm delighted with the progress being made.
But I'd still like to know... what happens when something breaks?
jchnhtfdMy previous post on this regarding my one concern with PTC (which hasn't been answered, somewhat to my surprise) having vanished for some reason, I'll briefly restate it: What happens when something in the system breaks? Having considerable experience with aircraft accident/incident investigation, I can assure folks that the magic does, in fact break. Not referring to bad programming (endemic) or operator error (also endemic) but just plain simply breaks. In the present signalling system, that usually means a dark signal (stop and find out what's going on) (yes, I know, there are ways in which a signalling failure can result in a false clear, but they are pretty rare). In general, seems to me that some form of PTC is indeed a very good thing and should, in the long run (after amortizing the money) result in better -- perhaps much better -- productivity and lower costs, and I'm delighted with the progress being made. But I'd still like to know... what happens when something breaks?
Ah - sorry, I'd interpreted the earlier post as a rhetorical question rather than a question question.
Oh dear, failure modes. There is a long list that lead to the system refusing to do anything, which means the train stops right there, and the outcome is the railway is tied up, but trains shouldn't run into each other. But I think what you're looking for is failure modes that lead to an authority violation or an overspeed or open switch being run through. Most of those failure modes have at their root someone failing to update a change in system input data: a new turnout is installed, but the database isn't updated, or a signal is moved, and the database isn't updated.
The Wabtec platform puts all the processing power and control on-board the locomotive. There's no requirement for handshakes with the central dispatching server except when an authority is extended or created. Failure modes there consist of information drops which leads to no valid authority being issued. The onboard computer uses tandem processors -- both have to agree for something to happen.
Unlike aircraft there is very much less input into the system. The inputs consist of a track database (uploaded and stored in memory), an authority (issued by the PTC server), a location (deduced from GPS, track tag, and axle count inputs), and peer-to-peer querying of wayside interface units (on turnouts, fixed signals). A failure of a WIU is the same as what you get now when a switch-circuit controller doesn't work or a signal gives a false clear -- the WIU consists of two wires to a radio, and if it tests the first time it doesn't change. But a switch-circuit controller can be out of adjustment (just like now) and call a switch closed when in fact it's open. The architecture is simple, on purpose.
A common failure mode is the locomotive not mapping itself to its track database. The database says, for example, "I have according to the logical network and my axle odometer proceeded 5,000 feet timetable west on track #100002 since my last good GPS fix which means my GPS waypoint should be XXX/YYY. But my GPS antenna says I am at at XX1/YY1. That's not possible, either the database is wrong or my GPS is wrong, so I quit, and I'm stopping here."
More than this, I'd have to start emailing you pdfs. It's hard to explain a negative, and that's what your question consists of: "How do I know this is reasonably perfect." The answer is, you don't. But there is a lot of test data out there from the Beardstown Sub on BNSF and some other test platforms, and if you read 49.236 Subpart H, you'll know a lot more about how demanding the proof has been.
erikemRWM,Are the 12 frequencies you've mentioned for ATC use or for audio frequency overlay?I'd be pretty sure that a continuously variable ATC speed signal is possible (or something that has enough steps to be close enough). The tricky part would be ensuring that the ATC receiver is picking up something that can only be an ATC speed control signal - mistaking a stray signal for an ATC speed limit signal is a great recipe for disaster. I shouldn't be surprised that audio frequency overlays can have problems in estimating distance - there are some parallels with what I'm doing at work. Another method that could work is using a magnetic sensor to detect the presence of a train within a few feet of the sensor (problem here is either doing the wiring or replacing batteries for a wireless sensor).Anyway, it is probably cheaper to go straight to PTC than to implement a souped up ATC.- Erik
About a dozen each for both the ATC and the grade crossing predictors. That is all the manufacturers are willing to certify as safe.
The active track transponder you reference in your second paragraph is the usual method for knowing distance to a target. Those things are quite expensive. The ACSES system in the NEC in fact has gone that route.
The cost difference I'm seeing for making ATC or some sort of intermittant cab-signal system work vs the Wabtec platform is 3:1.
Thank you, RWM! Really what I was looking for, and actually a two part answer. First part -- people are looking at the problem, and realistically (not to tread heavily on toes, but have you ever tried to convince the folks at EADS that the software in their fly-by-wire does NOT have a fail operational mode for some stupid mechanical failure? Like wonky integrated starter/generators on GE CF6 engines? No? Don't, if you value your sanity) and second that, in general, a failure is a fail safe (fail stop). Expensive, but at least you can park a train...
And it makes me very happy that the Wabtec system is on-board. That, I like.
Railway ManThe cost difference I'm seeing for making ATC or some sort of intermittant cab-signal system work vs the Wabtec platform is 3:1.
Sounds reasonable and thanks for the data point. My point was that a lot of what PTC does could be done with enhanced ATC, but that's emphatically not the same as saying that an enhanced ATC should be done instead of PTC.
On a similar note, there's a lot of interest in using wireless sensor networks on the factory floor - one tidbit was that the cost of providing a wired connection was about $40/foot - probably something similar for a railroad.
Topic divergingly, slightly...
I have read three of Wm Langewiesche's articles and highly recommend them. The before referenced article on the collision at 37,000 feet was excellent.
The other two were accounts of Piracy (very appropriate based on the recent activities) and last night was his look at the space shuttle's 2003 mishap. The look at NASA was extremely descriptive and informative.
Langewiesche's articles are archived on both Vanity Fair and Atlantic. Fair warning...these articles are well written and very long, each taking an hour or so. He sets up each story quite well and leaves you very well informed.
Railway Man [snips] Langweische is my favorite author, by far. No one else gets the technical details as right, explains them as clearly, or turns a phrase so eloquently. If the last paragraph in the "Devil at 37,000 feet" article doesn't make you shiver, you might be dead from the neck up. Patrick Smith, the "Ask the Pilot" columnist and a 767 captain, said that Langweische made exactly one technical mistake in the "Devil" article, a very minor one, misnaming a control center, which might have been a spellcheck error in fact. That's as impressive a recommendation as you can get. RWM
Note: For those who've been following the "Devil at 37,000 Feet" aspect of this thread, you may be interested in the following blog dated March 11, 2009 that I ran across earlier this morning. It appears to be by Joe Sharkey - the reporter/ writer for Business Jet Traveler magazine who was also aboard the Embraer Legacy private aircraft:
http://joesharkeyat.blogspot.com/2009/03/enough-already-vanity-fair.html
As you'll see, Sharkey's neither happy with Langewiesche nor very impressed by the article. It feels to me like Sharkey's straining pretty hard to find a basis to be able to righteously proclaim that he's been insulted by Langeswiesche. But I'd have to reread both the Vanity Fair article and Sharkey's blog post to make my tentative conclusion more definitive, and I don't have the time for that right now.
Paul:
I agree with your assessment...didnt quite catch the "pile on Joe Sharkey" portion of the article. Perhaps it wasnt there. Sharkey was mentioned a couple of times in the article, but not in a negetive manner. Perhaps he is a bit upset that an article was written by another writer, instead of the one who should have naturally gotten the byline.
It was very well written and seemingly very fair to everyone.
Paul, if you have a chance, invest an hour and read the one in Atlantic (archived) on the space shuttle crash. Very well written and documented. His understanding of aviation gives him a great advantage, plus the ability to recount the actual events with well researched and documented information.
MP173Paul: I agree with your assessment...didnt quite catch the "pile on Joe Sharkey" portion of the article. Perhaps it wasnt there. Sharkey was mentioned a couple of times in the article, but not in a negetive manner. Perhaps he is a bit upset that an article was written by another writer, instead of the one who should have naturally gotten the byline. It was very well written and seemingly very fair to everyone. Paul, if you have a chance, invest an hour and read the one in Atlantic (archived) on the space shuttle crash. Very well written and documented. His understanding of aviation gives him a great advantage, plus the ability to recount the actual events with well researched and documented information. ed
Someone who came to the article from the "Ask the Pilot" (Patrick Smith) reference, like I did, knew about this conflict between Langewiesche and Sharkey. Smith though that Langewiesch was too hard on Sharkey, but that it was a minor, tangential sideshow in the article.
Sharkey is not the person that could have written that article. He's a business-travel reporter, not an industry or technical reporter, that's compromised himself with too many boondoggles, too many encomiums, too many paens to the industry. His market is the high-end, first-class, and private-jet passenger, and his source is the marketers for the airlines and the airframes. He is compromised from unabashedly sitting down and writing, "hey, guess what, some of this 'magic' doesn't work." That is not a story his market or his sources want to read.
ed -
Thanks for the 2nd opinion on the "balance" of the Langewiesche article. You've summarized my "take-away" understanding of Sharkey's role in it - essentially an informed but uninvolved bystander. Also, him having a "sour grapes" attitude is pretty plausible in the circumstances.
Yes, I've already printed the pertinent portions of this thread and squirreled it away to remind me to read the space shuttle and Somalian (?) pirates articles. I appreciate the recommendation and also the estimated reading time for it. I'm not a "Type A" personality maniac for scheduling life down to the minute, but with web pages of unstandardized lengths it can be hard for me to know quite what I'm getting in to when I start reading something as detailed and fact-specific as these articles. While reading "The Devil at 37,000 Feet" I remember thinking it was going kind of slow, but I had quite a few interruptions that morning, too.
RWM - I concur with your "tangential sideshow" summary of Sharkey's role in Langewiesche's article. As far as Sharkey's "street cred"[ibility], it then appears to be - logically enough - more as a "trade press" writer than a researcher or investigative reporter/ journalist (if I'm using any of those "terms of art" correctly, because that's another world that I'm not terribly familiar with), who doesn't have to worry about "biting the hand that feeds him" / conflict of interest kind of thing. You know more of the background there than was apparent from Sharkey's protest, and that helps to assess and place it into proper perspective. This morning I was going to write, "Methinks he doth protesteth too much" - well, it seems I should have !
Having been the aviation business for a long time and working on safety issues for 15 years I have the utmost respect for the NTSB. They have mostly been very astute in their recommendations. Human factors has been the hallmark of their decisions. Human factors? the accident at Tenneriff of Pan Am and KLM was a litany of human errors resulting in 500+ fatalities. EAL 401 into the swamp near Miami. More human factors with a few mechanical and warning displays (aspects) thrown in 180+ deaths. These were examples that I taught to my classes and the lesson got thru to some of them. The NTSB recommendations have definitely saved many lives in the aviation industry and the other transportation areas as well.
Now of all aspects displayed on RR signals I feel that restricted is the most precarious. Red - you stop. Yellow / flashing yellow - proceed at some approach speed. Green - proceed at track or interlocking speed. Since either a lunar or flashing red means restricted in some rule books then that should be a standard. When you can look in the same rule book and under rule 286 (R over Y) you have medium approach and rule C-290 (R over Y) you have restricting then human factors are going to happen sooner or later. I've even observed NJ transit use flashing red at Hoboken terminal to signify restricted instead of a R over Y or a R over R over Y (they are on NOROC rules ?)
Now for the accident site in question. Was the siding a non signaled or signaled siding? If non signaled then the lower Y could easily be changed to a lunar as CSX is doing on their unsignaled sidings. If signaled then an additional target will be needed to give a R over Y over Y to provide for a medium approach.
What does the two above paragraphs mean? Any good lawyer is going to present this argument and a jury will buy it. The NTSB report is going to be very damming. This is the reason that restricting needs no ambugity.
r
The accident site in question was on NS, not CSX. And no siding was involved--the train was crossing from one main track to the other.
On the Railway Age news site this morning:
The National Transportation Safety Board makes the following recommendations to the Federal Railroad Administration: establish uniform signal aspects that railroads must use to authorize a train to enter an occupied block, and prohibit the use of these aspects for any other signal indication; study the different signal systems for trains, identify ways to communicate more uniformly the meaning of signal aspects across all railroad territories, and require the railroads to implement as many uniform signal meanings as possible
blue streak 1Having been the aviation business for a long time and working on safety issues for 15 years I have the utmost respect for the NTSB. They have mostly been very astute in their recommendations. Human factors has been the hallmark of their decisions. Human factors? the accident at Tenneriff of Pan Am and KLM was a litany of human errors resulting in 500+ fatalities. EAL 401 into the swamp near Miami. More human factors with a few mechanical and warning displays (aspects) thrown in 180+ deaths. These were examples that I taught to my classes and the lesson got thru to some of them. The NTSB recommendations have definitely saved many lives in the aviation industry and the other transportation areas as well. Now of all aspects displayed on RR signals I feel that restricted is the most precarious. Red - you stop. Yellow / flashing yellow - proceed at some approach speed. Green - proceed at track or interlocking speed. Since either a lunar or flashing red means restricted in some rule books then that should be a standard. When you can look in the same rule book and under rule 286 (R over Y) you have medium approach and rule C-290 (R over Y) you have restricting then human factors are going to happen sooner or later. I've even observed NJ transit use flashing red at Hoboken terminal to signify restricted instead of a R over Y or a R over R over Y (they are on NOROC rules ?) Now for the accident site in question. Was the siding a non signaled or signaled siding? If non signaled then the lower Y could easily be changed to a lunar as CSX is doing on their unsignaled sidings. If signaled then an additional target will be needed to give a R over Y over Y to provide for a medium approach. What does the two above paragraphs mean? Any good lawyer is going to present this argument and a jury will buy it. The NTSB report is going to be very damming. This is the reason that restricting needs no ambugity.
Bluestreak -- I'm not a lawyer (and did not stay at a Holiday Inn Express last night) but the NTSB recommendations change nothing about the exposure to liability as far as I can see. Two trains ran into each other. They're not supposed to do that. Passengers have a reasonable expectation when they get on a train that they'll arrive the other end sans collision. Those facts are not doubted.
I think the question you and others are alluding to is that railways have become grossly neligent, that the use of restricted speed, restricting indications, and different signal aspect and indications among railways is so risky and so unsafe that it should never be used. Anyone is welcome to make that argument in court, and probably will, but that doesn't mean they are inevitably destined to win. The number of actual casualties where failure to adhere to restricted speed or misreading signal aspects had a role, is a really small number. Calling that grossly negligent to me seems like saying that a hotel that permits you to step into a bathtub without having a properly secured slip-and-fall protection harness provided by and hooked up by the hotel is grossly negligent. Level of risk matters. There are far bigger risks than these.
There's no natural law that defines a sharp boundary between acceptable risk and unacceptable risk. Industries, technology, and social expectations evolve, and the boundary moves. I don't see the recommendations of the NTSB in this case as being even remotely close to the line where the cost of eliminating the risk is equaled by the benefit to society received. Risk reduction costs money. My opinion is we should spend money to eliminate the big risks with proven high casualty costs, then as we have money left over, work down toward the little risks. The number of people killed by train-motor vehicle collisions is more than 100 to 1 as great as the number of people killed in train-train collisions. Is it smart to pour all our money and attention into removing the splinter from the little finger of a patient who has blood gushing from an severed artery?
Railway Man blue streak 1 [snips] What does the two above paragraphs mean? Any good lawyer is going to present this argument and a jury will buy it. The NTSB report is going to be very damming. This is the reason that restricting needs no ambugity. Bluestreak -- I'm not a lawyer (and did not stay at a Holiday Inn Express last night) but the NTSB recommendations change nothing about the exposure to liability as far as I can see. Two trains ran into each other. They're not supposed to do that. Passengers have a reasonable expectation when they get on a train that they'll arrive the other end sans collision. Those facts are not doubted. I think the question you and others are alluding to is that railways have become grossly neligent, that the use of restricted speed, restricting indications, and different signal aspect and indications among railways is so risky and so unsafe that it should never be used. Anyone is welcome to make that argument in court, and probably will, but that doesn't mean they are inevitably destined to win. The number of actual casualties where failure to adhere to restricted speed or misreading signal aspects had a role, is a really small number. Calling that grossly negligent to me seems like saying that a hotel that permits you to step into a bathtub without having a properly secured slip-and-fall protection harness provided by and hooked up by the hotel is grossly negligent. Level of risk matters. There are far bigger risks than these. There's no natural law that defines a sharp boundary between acceptable risk and unacceptable risk. Industries, technology, and social expectations evolve, and the boundary moves. I don't see the recommendations of the NTSB in this case as being even remotely close to the line where the cost of eliminating the risk is equaled by the benefit to society received. Risk reduction costs money. My opinion is we should spend money to eliminate the big risks with proven high casualty costs, then as we have money left over, work down toward the little risks. The number of people killed by train-motor vehicle collisions is more than 100 to 1 as great as the number of people killed in train-train collisions. Is it smart to pour all our money and attention into removing the splinter from the little finger of a patient who has blood gushing from an severed artery? RWM
blue streak 1 [snips] What does the two above paragraphs mean? Any good lawyer is going to present this argument and a jury will buy it. The NTSB report is going to be very damming. This is the reason that restricting needs no ambugity.
Well, there's about 20% of a semester of a good law school's course on Torts (which includes, but goes beyond, negligence theory) in what RWM wrote above. Some supplemental comments and observations:
- NTSB findings and reports are totally inadmissible in any civil or criminal proceeding arising out of the accident. The NTSB may provide a great "road map" for the claimant's lawyers to get to the same evidence with their own experts by using a sharply focused "discovery" process (subpoenas, depositions, requests for production of documents, examinations of equipment, requests for admissions, etc.) without having to totally "re-invent the wheel", but the lawyers will have to go through that formal process to be able to accumulate, analyze, and present that evidence and findings as their own at a trial or any mediation, arbitration, settlement negotiations, etc.;
- "Res ipsa loquitur" is the Latin phrase meaning "the thing speaks for itself". That doctrine applies to both of RWM's points - trains aren't supposed to do that, and passengers have a reasonable expectation that they won't. Hence, the claimant's don't have near as much a burden of proof of 2 of the 4 classical elements of a negligence action - "duty/ standard of care" and "breach of same". Alternatively, the doctrine - particularly for a common carrier - may enable use of a "strict liability" theory, which pretty much dispenses with the duty and breach parts, and gets right down to the causation and damages (injuries) elements;
- We're probably making a liability mountain out of a safety molehill here (I meant to post this thought before, but probably couldn't due to one of the numerous recurring "Oops - something has gone wrong" error message problems here). This accident had a remarkably small number of casualties, as I recall. While something like 75 went to the hospital, I believe that only 6 were admitted - none were seriously injured, and no one was killed. I don't know how many other similar accidents have occurred - either freight and/ or passenger - but it's not my understanding that this is a common problem or one that invariably causes severe risks - compare with the Chatsworth wreck. While fixing this seems like a "no-brainer", in the grand scheme of things there are probably other problems that need fixing more urgently, as RWM points out - such as sleep deprivation / circadian rhythym-caused or related accidents, which are a recurring problem;
- The NTSB is "unencumbered by the economic process" [shamelessly adapted from Click & Clack's CarTalk "unencumbered by the thought process" put-down]. It's the NTSB's job to be the watchdog and identify anything that might need to be fixed - note that they usually have from several to many recommendations in each of their formal reports. It's up to other agencies and organizations - such as the railroads themselves, the FRA, Congress, the courts, etc. to look into those recommendations further to see if they are reasonable = make sense from the standpoints of either cost-benefit, efficiency, safety of passsengers/ crews and other human lives, moral grounds, and/ or security, etc. That's where the analysis, balancing and trade-offs of fixing problem A or B or C and the relative costs and benefits of same are worked out, argued, and decided, not by the NTSB. That's not to say that the NTSB isn't right or justified in their conclusions and findings - it's just that in our system that's been set up, it's not the NTSB's role to mandate implementation of its recommendations;
- The railroads, in contradistinction, have direct exposure to the economic consequences of their actions or inactions. Without getting into a dissertation here, a brief theory of strict liability is that by making the carriers essentially 100% responsible for any and all damages and injuries suffered by their passengers, it forces the railroads to "put their money where their mouth is". Under the old-style negligence theory, the railroad would be liable only if the claimant could shown that the railroad been careless in some regard, and that the claimant was utterly blameless (for example, any "contributory negligence" - even 1 % - by the claimant was a complete - 100 % - bar to any recovery). That can be a tough burden of proof, and if that couldn't be accomplished, the result was that the railroad paid and the claimant received nothing, even though the claimant had clearly been injured. From an economic perspective, in such cases the railroad got off completely free - it had no monetary incentive to change anything or improve safety as long as it met the bare minimum "standard of care" as viewed by the often pro-business interests courts of that day - even though it might have been partially at fault, which I believe is technically referred to as "external dis-economies". Over the years that wasn't working out too well - for a variety of legal and extra-legal reasons - so society and the courts adapted by creating/ applying the doctrine of strict liability. The doctrine of strict liability has the effect of imposing and internalizing all of the costs of accidents to the railroad, so it suffered right along with and as much as its victims. Thus - in theory - any cost vs. benefits calculation of possible safety improvements should take into account the full reduction of costs resulting from lower damage and injury claims. Therefore, the railroad - acting in its economic and moral self-interest - will naturally seek to implement those safety changes with the highest return on investment / costs - which tend to minimize the injuries and reduce damages. Accordingly, what we should see is that the railroads fix the big problems first, and defer the minor ones until "later". What their actions tell us in this instance is that they view the "Restricting" signal confusion problem as one of the minor problems that doesn't need an immediate fix. Actual experience - such as this relatively rare accident - seems to support that view.
Enough philosophizing and theorizing for now. "Back to the salt mine with ye!"
Railway Man Moreover, ATC can't do a lot of things that PTC will do, except with expensive, complicated, ad hoc, inflexible, inefficient, and capacity-robbing workarounds: It cannot consistently stop the train short of the signal (requires predictive braking). It cannot enforce restricted speed It cannot put two trains into the same block and and keep them from colliding It cannot enforce permanent speed limits (curves, bridges, tunnels) It cannot enforce temporary speed restrictions (Form As, General Orders, Track Bulletins) It cannot enforce work zone limit It does not work in dark territory It cannot be installed without creating enormous problems with trade-crossing signaling because of frequency conflicts, which means several billion more to redo thousands of grade-crossing predictors. It cannot be low-maintenance I can make an ATC system do all of these things listed above, but no one will like the price tag or the harm it does to railway capacity
I can make an ATC system do all of these things listed above, but no one will like the price tag or the harm it does to railway capacity
RWM: Could not find my copy of TRAINS that had the article on AMTRAK's ACSES signal system. What I remember it could do most of the above items except #1. Your comments will be appreciated. Do you have any cost comparsions of it to ATC and PTC? I will post later my concerns about using a GPS based system.
blue streak 1Railway Man Moreover, ATC can't do a lot of things that PTC will do, except with expensive, complicated, ad hoc, inflexible, inefficient, and capacity-robbing workarounds: It cannot consistently stop the train short of the signal (requires predictive braking). It cannot enforce restricted speed It cannot put two trains into the same block and and keep them from colliding It cannot enforce permanent speed limits (curves, bridges, tunnels) It cannot enforce temporary speed restrictions (Form As, General Orders, Track Bulletins) It cannot enforce work zone limit It does not work in dark territory It cannot be installed without creating enormous problems with trade-crossing signaling because of frequency conflicts, which means several billion more to redo thousands of grade-crossing predictors. It cannot be low-maintenance I can make an ATC system do all of these things listed above, but no one will like the price tag or the harm it does to railway capacity RWM: Could not find my copy of TRAINS that had the article on AMTRAK's ACSES signal system. What I remember it could do most of the above items except #1. Your comments will be appreciated. Do you have any cost comparsions of it to ATC and PTC? I will post later my concerns about using a GPS based system.
ACSES can do all of this 7, 8, and 9, but the cost is high. On the other hand, the train-control environment and operating regime on the NEC is not the same as on other lines, thus costs are not strictly comparable. There are also very few grade crossings on the NEC, so that is much less of a problem.
ACSES is kind of like trying to make a diesel locomotive from a steam locomotive by bolting on parts and beating it with a hammer.
It starts with PRR 4 aspect coded cab signal and suppression braking speed control (and later, Conrail's goofy quasi-predictive LSL speed control) and tries to make it do things it never was designed to do. It was a wonderful thing in 1950, but....
First, more signal aspects were needed to accomodate higher speed crossovers, so a second layer of cab signals was added. But, that doesnt' easily handle curve and civil speed restrictions, to they layered on track trasnponders, which gives you two separate systems, each trying to independently say something about authorized speed..
To make matters worse, they display BOTH of these authorized speeds to the engineer, making the governing one bright and the other one dim. Not exactly a good man-machine interface.
The only good news is that it's generally backwards compatible with the PRR cab signal/LSL system, so NS and CR can run their trains over the NEC, although I don't know how they'll accomodate a "positive stop".
Can you tell I'm not a fan?
Good analogy Don.
It's a warm, fuzzy solution for those who think that if you can't hear a relay ticking in the instrument house, it couldn't possibly work.
Railway Man Good analogy Don. It's a warm, fuzzy solution for those who think that if you can't hear a relay ticking in the instrument house, it couldn't possibly work.
Sounds like you've met "the godfather of ACSES" somewhere along the line.....
tree68 How many years did it take for "right turn on red" to make it across the country?
It only took long enough for either Richard Nixon or Gerald Ford--I can't remember just which one was in office at that particular time--to affix his signature at the bottom of a piece of paper called a Bill.
When your Air Force transfered me to Leftover Air Force Patch in Massachusetts in 1964 I had to attend a base briefing. The moderator in this briefing cautioned all us new arrivals that if we were from the west where right turns on red were allowed they were prohibited in Massachusetts. "Massachusetts," he said, "does not allow right turns on red because, when all is said and done, Massachusetts uses rotary intersections to confuse drivers and Massachusetts drivers can only handle one confusion in a lifetime!". My downstairs neighbor who hailed from Rhode Island speculated that Mass drivers were too adle-brained to understand that they were going to have to stop and check for cross traffic before turning into the intersection
Congress mandated "right turns on red after coming to a full stop" in either 1974 or 1975. It was done as an energy conservation measure--I remember a figure bandied about that about 3% of all gasoline was wasted at red lights by drivers waiting to make a right turn--and carried a provision that states were required to post signs at locations where "right turns on red after coming to a full stop" were prohibited. Massachusetts promptly put up prohibition signs at every intersection which drew the flat of the federal government's blade; right turns on red could only be prohibited for compelling reasons of safety. When I read about this in a newspaper I could not help but remember that briefing of a decade earlier. I have not been back to Massachusetts since I left in '65 but I have often wondered just how Massachusetts came to grips with those compelling reasons of safety. I know they didn't but I wish the government had outlawed those rotary intersections at the same stroke!; I made many, many flat-wheel stops trying to navigate my way through those intersections. Guess I might be a little adle-brained myself.
In regards to signal standardization the only way this could occur is if it were mandated by federal law--and that, of course, can only be accomplished with federal specifications. What might these specifications be? and remember the old rejoinder about the horse designed by a committee. (For those uninformed readers this bromide states that a horse designed by a committee is likely to look like a camel.) Any study is likely to look at existing systems to draw conclusions of efficiency . . . . . . . . . . and once this committee has come to its conclusion and ordered compliance to a set of specifications who is going to pay for it. Some roads might even find the expense prohibitive to continued operation while others could find the cost of compliance relatively minimal.
If anything should be standardized it is the automobile industry. Did you ever pick up a rental car at an airport and it takes you ten minutes to figure out how the radio works and another ten minutes to figure out how to manipulate the heat and air conditioning and still another ten minutes to decipher the intricacies of the cruise control.
Standardization should be left to (possible) agreement within the industry. Everytime I hear the word standardization--particularly standardization through some kind of governement fiat--I think of that ditty from the 50s about the:
Pretty boxes on the hillside;
Pretty boxes made of ticky-tacky;
Pretty boxes;
Pretty boxes all the same.
From the far, far reaches of the wild, wild west I am: rtpoteet
Railway Man There are also very few grade crossings on the NEC, so that is much less of a problem. RWM
There are also very few grade crossings on the NEC, so that is much less of a problem.
I have been reading all posts and see logic in all,however I would like to remind those of how the Car makers resisted seat belts and such because of cost. How many lives has Ralph Nader saved over the years? I asume that air trafic and runway control thru out the world is standardized at least I hope.
aut1rml I have been reading all posts and see logic in all,however I would like to remind those of how the Car makers resisted seat belts and such because of cost. How many lives has Ralph Nader saved over the years? I asume that air trafic and runway control thru out the world is standardized at least I hope.
Actually, it was the car buyers that resisted seat belts. In the mid 1950's Ford focused on safety offering seat belts in their cars - advertising this heavily. Chevy focused on performance, pushing their small block V-8. Chevys sold. Fords didn't. Ford gave up trying to sell safety.
Even after the gov't mandated seat belts, starting with front lap belts only in 1964, hardly anybody would wear them. Usage was around 10% through most of the 1970s. It wasn't until the usage laws came into effect that usage started to climb.
Ralph Nader, as far as I know, had little to do with the push for seat belts. It was the Chevy Corvair where he made his mark. (although his book didn't get published until after Chevy had already fixed the car's problems)
Interest in safety didn't really climb until the baby boomers started having kids.
blue streak 1 Railway Man There are also very few grade crossings on the NEC, so that is much less of a problem. RWM This brings up a burning question that I haven't asked. How much savings on signal costs are available on ABS, CTC, ATC and PTC if a grade crossing is eliminated. Of course the number of other crossings in range of a crossing, # of tracks, any interlockings in range, etc. would affect the cost. As I remember all grade crossings (auto) have been eliminated NY - WASH sometime after AMTRAK. anyone know a date? If the cost of grade crossings on PTC installations are as great as has been stated here could that be another reason for wholesale grade crossing eliminations before activating the PTC.
Wikipedia says 1976, under the heading of "Grade Crossings" a little before halfway down the page - but I think that's too early - I think early 1980s:
http://en.wikipedia.org/wiki/Northeast_Corridor
Supposedly it was Springfield Road new Bowie, MD - under "Amtrak 2002" about 90 % of the way down the page:
http://www.trainweb.org/oldmainline/pa1.htm
1981, per the Brotherhood of Locomotive Engineer's "Today's News" for Friday, Sept. 10, 1999, under the heading "Amtrak will upgrade safety devices in the Northeast", about 2/3 of the way through that item, which says "The last grade crossing south of New Haven was closed 18 years ago in Baltimore.", at:
https://www.ble-t.org/pr/archive/headline0910a.html
That matches with my recollection - I spent most of 1983 at the nearby Aberdeen Proving Grounds (Maryland), and there was a fairly new bridge in downtown Aberdeen that allowed the closing a a major crossing there.
Hope this is helpful.
Is most of the NE Corridor sub terrainian, ground level, or elevated...or is it a mixture?
Really, a mixture.
Most of the NEC is elevated at least slightly on embankments, for drainage and a result of grade-crossing elimination when constructed or later projects in the cities and built-up areas.
The only subterranean stretches are in the big cities - beyond Washington Union Station, Baltimore, Philadelphia, Trenton, New York City, and maybe a couple further north. Most of that ranges from a few blocks to a mile at most, except for NYC.
Elevated on bridges/ trestles is pretty much only at the bridge approaches across the various rivers.
Ground level is not uncommon, but with the above most of that is in the open areas of NE Maryland and Delaware, across NJ, and Rhode ISland and Massachusetts.
Our community is FREE to join. To participate you must either login or register for an account.