The Wreck of Amtrak 188
nytimes.com
nytimes.com
> In much of Asia and Europe, engineers are protected by a technology known in the United States as positive train control, or P.T.C...Amtrak has been working on its own in-house version of P.T.C., called the Advanced Civil Speed Enforcement System, or Acses, for almost a decade. But owing to insufficient funding and a row with the F.C.C., which Amtrak said had been slow to approve the use of the requisite radio bandwidth, its actual implementation has been piecemeal. At the time of the accident, large portions of the Northeast Corridor, including Frankford Junction, were not online. Practically speaking, that meant engineers were working with no safety net.
Near the end of the story:
> In late May, Joseph Boardman, Amtrak’s C.E.O. and president, promised that the installation of P.T.C. on the Northeast Corridor would be completed by the end of 2015, a pledge he has kept: Today, the system is active on all routes, with the exception of substantial stretches of track owned by the State of Connecticut. (A spokesman for the Connecticut Department of Transportation said it hoped to have P.T.C. installed on all state-owned track by 2018.)
A technology that had stalled for a decade -- for ostensibly "hard" and "complicated" reasons -- is completed within months after a disaster. Just goes to show how much tragedy and politics has an effect on implementation and prioritization of engineering improvements.
EDIT: but yes, it's highly political. It's sickening as someone that grew up not far from where this accident happened and still travel the NE Corridor several times a year.
The national scorecard for 2013:
Dams D
Drinking Water D
Hazardous Waste D
Levees D-
Solid Waste B-
Wastewater D
Aviation D
Bridges C+
Inland Waterways D-
Ports C
Rail C+
Roads D
Transit D
Public Parks & Recreation C-
Schools D
Energy D+
As someone living in Michigan, perhaps it was propped up (to the national average, which is already terrible) by the various municipalities that are fairly wealthy and funded.
And no, the 'size' of the US isn't a very good excuse. If a backwater road in Minnesota is run down, ok, but we're talking about major infrastructure in urban areas.
So my question is this: Car navigation as a problem set is similar but massively harder than train navigation. My car can tell me speed limits, which lane to be in, and knows information about all major roads in the area.
Why don't trains have a Google Maps-like system? You have 1/100th fewer "roads," you have directional assurances, you have speed limits set by a single authority (no city, state, federal distinction, etc), and so on.
Heck if you've played Train Simulator you KNOW that they have all of this route information digitised somewhere. So why not just throw it in an app, hook up GPS, and get it deployed tomorrow instead of ten years from now?
Is this a classic example of over-engineering the problem?
A car stays in lanes that go one way. Trains don't: they often share a segment of track for both directions, and you better be darn sure you're not going to run head-on into an oncoming train, or into a stopped one.
Thus, trains need a lot more communications and coordination to ensure safety, unlike cars which use the rules of the road and quick maneuvering and stopping to adjust
Starting with this: https://www.fra.dot.gov/Elib/Document/2189
"(3) POSITIVE TRAIN CONTROL SYSTEM.—The term ‘positive train control system’ means a system designed to prevent train-to-train collisions, over-speed derailments, incursions into established work zone limits, and the movement of a train through a switch left in the wrong position."
The deadlines, definitions, etc, don't line up well with a "What can we do now, with existing tech, that would add value at a low cost?" approach.
Navigation systems already do this for signal losses (and to save battery).
Public transportation is furthermore not an area of "hey I know, I just ask on Stackoverflow for an algorithm that counteracts the wear on the wheels". They do extremely conservative and defensive programming there (I once upon a time read the source code of one of the leading ETCS systems) in extremely restricted and conservative hardware (embedded 8080's in the 2000's) where the production process is audited and nailed down for everything (CF cards costing hundreds of $ for 128MB).
Absolutely nothing is trivial there - the usual answer for an improvement idea would be a resounding "no way!". They are mortally afraid of the law of unintended consequences there.
When SA was turned off in 2000 it was irrevocable. GPS satellites designed since that date do not carry the SA feature capability.
Really the biggest flaw of the US's push for PTC is reinventing the wheel: ETCS[0] has been standardising this all over Europe (with parts, such as GSM-R, being adopted in large parts of the world!), and the goals for PTC largely match up with ETCS Level 2, as far as I'm aware. There are a number of off-the-shelf systems available, leaving the largest issue as GSM-R frequency acquisition. And, I suppose, the political issue of using a non-American system.
ETCS Level 3 essentially allows pure-radio positioning, but there's currently no planned deployments because nobody yet has constructed a system that meets the required "safety integrity level". Note that one of the issues here is you need devices at both the lead and rear vehicles to ensure train integrity, whereas currently typically one only has such equipment in the driving vehicle(s). There's hope to use the EGNOS satellite augmentation system to get better accuracy guarantees than GPS/GLONASS/Galileo provide, but it's all still experimental, and the only experimental project there failed.
[0]: https://en.wikipedia.org/wiki/European_Train_Control_System (an article which I will openly say defines far too little jargon it uses!)
Your car navigation isn't "positive control." It can't slow your car down for you, and when it fucks up (like Uber's navigation does 50% of the time on the way to Union Station), it can't fuck up control of the car. It's a fundamentally advisory system that is not designed to be trusted (and very often is not trustworthy). You could hack together an app to tell an Amtrak driver the speed limit in any given location, but that wouldn't have helped Amtrak 188. To prevent that crash you needed a system that can override the train operator and slow the train.
Once you give the computer authority to override the driver, a huge amount of complexity sets in.
First, a substantial portion of the Northeast Regional track does not have cellular coverage. The trains have no way to communicate information in those areas. If you're PTC is going to slow down a train in a dead zone, it's not going to be acceptable to not be able to relay that information off the train. That requirement drove the system design. A big part of the delay in deploying PTC was setting up the necessary wireless communications infrastructure.
Then there is the issue of integrating with the existing signaling system. Your car navigation doesn't interact with the signal lights and tell you when to stop. The PTC needs to be able to do that. It'd be a recipe for disaster to have a computer system that can slow down or stop a train but had no idea what the signaling system was doing.
AEB systems can, though: http://www.euroncap.com/en/vehicle-safety/the-rewards-explai...
Couldn't the train's computer simply advise the engineer (that's the guy controlling the train correct?) to slow the hell down when traveling too fast in a particular zone? Would that not be a step in the right direction? Maybe the system could even require that the engineer dismiss the warning by actually applying the brakes. Maybe after that doesn't happen the train can apply the brakes for you.
That doesn't seem that complicated. I'm not trying to be argumentative. I'd love to hear some specifics about what complexity that adds.
The train doesn't strictly need to know where it is — just what the maximum speed at that location is. Electronic pulses through the rails are one option, or transmitters at speed limit changes; presumably there are other ways too.
¹ The parts with safe trains, anyway.
Why are humans even in this particular loop? It's a train, not a car or an aircraft! It's not going anywhere it didn't go before, and it has no business going 1 MPH faster or slower past any given point on the track than it did the last time! You could implement a half-dozen fail-safe redundant controls for less than what it takes to pay an engineer to sit there and do a robot's job poorly.
The problem with the rail network is figuring out this backup system.
And unaided humans are perfect. Got it.
The problem with the rail network is figuring out this backup system.
Well, considering there's no backup system in place on many routes now, I'd say even the flakiest iPhone speed-alarm app is better than nothing. I can program my car to tell me if I exceed the speed limit. I'm sure multiple people will chime in to tell me several very good reasons why trains can't do that (or downmod me for asking.)
In this case it might not have been enough to save the train, though, if the speculation is correct about the engineer being temporarily knocked out due to hitting his head while ducking a rock that might or might not have been chucked through the windshield.
Wow, it's 2016 and I just typed that. I feel like I fell down a rabbit hole that leads straight to the 1890s.
"reliable enough" != "perfect". You're strawmanning the parent.
As for downmodding, if you goad people to do it, you lose the right to complain about it.
In a rational world, the burden of argument would fall on those who advocate human control of trains, not on those who simply can't fathom why they're not already automated.
Sometimes it makes sense to call out stupidity for what it is... even on HN. I'm not trying to come across as personally disrespectful.
Similarly, in a rational world, anyone advocated that X control the train should have to present their arguments. 'automation' doesn't 'win by default' - people favouring automation still have to present their arguments. 'automation' is not the null hypothesis here.
You: In a rational world, people wouldn't suggest that a $100 off-the-shelf GPS is all you need to retrofit a train to be automated enough to remove the human overseer.
And I'm the guy with the lighter and the pile of straw?
However, just because I made an error (or even strawmanned) doesn't mean that you're not strawmanning.
A better question is why didn't the USA adopt European train control systems. Those are well regarded, and many countries buy them. Is it a lack of budget, political will, or "not invented here"?
Which is why you don't expect it to work with no redundancy. Right now there's no redundancy.
Just as one example: what could possibly be an easier application for inertial navigation than a goddamn train?
and is susceptible to interference from high voltage power lines overhead.
No, it isn't. 60 Hz is a long way from 1575 MHz. Any GPS system that receives interference from nearby power lines is either broken, or so poorly designed that it should never have been placed on the market.
Hell, in my state, the electronic comms for trains get adversely affected by caterpillar plagues from time to time.
I think we're talking about very different vehicles here. These are avoidable hazards on the road. There is nothing a train driver can do except fill out the necessary paperwork afterwards, and likely spend some time on a therapist's couch.
Not even sound a horn to help alert the kids? Start slowing the train to give the kids more time to alert and escape, or reduce damage to the train and reduce chance of derailment in the case of the tree?
Trains don't stop on a dime, but neither do they take a mile of runway. I've been on a passenger train in the US South that had to do an emergency stop, and it stopped within it's own length.
Out of curiosity, why do you mix metric and imperial in the same context? Stopping distance in metric for a speed in imperial?
[1] https://en.wikipedia.org/wiki/Rail_speed_limits_in_the_Unite...
The official rules for driving cars in Britain have the same daft combination of units: https://assets.digital.cabinet-office.gov.uk/media/559afb11e...
First, there are two problems you want to solve with respect to train "position". One is distance along the track, and the other is which track it's on. The track centers are often 15 or 20 feet apart; GPS may not be good enough to determine which track it's on. There are other systems that determine that. But now you want to integrate those other systems with the GPS, and now the problem is much less simple than "there's this thing called GPS".
> Why are humans even in this particular loop? It's a train, not a car or an aircraft!
If you don't have absolute control of your right-of-way, you'd better have actual eyeballs up front. A car can stall on a crossing. Some drunk can be walking down the track. Some drunk can even be driving down the track. Somebody can even be trying to move a house across the tracks (I've seen a photo of the aftermath of that one).
And if you're going to say, "if the photos of the aftermath, the train didn't stop in time, so what's the point of the engineer?", well, the engineer can try to minimize the damage by seeing that some idiot is trying to move a house across the tracks, and coming as close as possible to stopping where he shouldn't have to stop at all.
> It's not going anywhere it didn't go before, and it has no business going 1 MPH faster or slower past any given point on the track than it did the last time!
Slower trains ahead of it. Temperature too hot, so sun kinks are possible. Temperature too low, so pull-aparts are possible. Too much rain, so a river may have washed out a bridge. Some kind of event right next to the tracks, so go slow and watch for people where they shouldn't be. Maintenance work on the track next door, so go slow and use the horn a lot, because sometimes those workers forget to pay attention to what's happening on the next track. Those are just off the top of my head.
Then there's BART, which did exactly what you said - they automated it. One day a train misread an instruction from a sensor, and tried to go 68 MPH when it should have been stopping for a station. The station happened to be the end of the (elevated) line. I forget whether that killed any people or not.
There's a lot more going on in a railroad environment than you think there is.
First, there are two problems you want to solve with
respect to train "position". One is distance along the
track, and the other is which track it's on. The track
centers are often 15 or 20 feet apart; GPS may not be
good enough to determine which track it's on.
How, exactly, would a train end up on the wrong track without being flagged by an existing sensing mechanism other than human eyes? That would be the problem to tackle first.
There are other systems that determine that. But now you
want to integrate those other systems with the GPS, and
now the problem is much less simple than "there's this
thing called GPS".
It's all about the fail-safe concept. If you know you're building an imperfect system, then you should build it such that the most likely failure modes result in temporary inconvenience rather than hot flaming atomic death. At some point, someone must have actively decided that this engineering principle shouldn't apply to trains. Otherwise simple sanity checks based on GPS, inertial measurement, or what-have-you would already be in place.
> Why are humans even in this particular loop? It's a
train, not a car or an aircraft!
If you don't have absolute control of your right-of-way,
you'd better have actual eyeballs up front. A car can
stall on a crossing.
Some drunk can be walking down the track. Some drunk can
even be driving down the track. Somebody can even be
trying to move a house across the tracks (I've seen a
photo of the aftermath of that one).
And if you're going to say, "if the photos of the
aftermath, the train didn't stop in time, so what's the
point of the engineer?", well, the engineer can try to
minimize the damage by seeing that some idiot is trying
to move a house across the tracks, and coming as close
as possible to stopping where he shouldn't have to stop
at all.
The train will generally win its fight against an errant pedestrian or a car or even a house, so the exact speed of the collision doesn't matter that much. To derail a train, something really stupid has to happen... like this.
>It's not going anywhere it didn't go before, and it
has no business going 1 MPH faster or slower past any
given point on the track than it did the last time!
Slower trains ahead of it.
Temperature too hot, so sun kinks are possible.
Temperature too low, so pull-aparts are possible.
Too much rain, so a river may have washed out a bridge.
Some kind of event right next to the tracks, so go slow
and watch for people where they shouldn't be.
Maintenance work on the track next door, so go slow and
use the horn a lot, because sometimes those workers
forget to pay attention to what's happening on the next
track.
while (maintenance_scheduled_nearby() ||
movement_detected_nearby())
{
speed--;
sound_horn();
}
Those are just off the top of my head. Then there's
BART, which did exactly what you said - they automated
it. One day a train misread an instruction from a
sensor, and tried to go 68 MPH when it should have been
stopping for a station. The station happened to be
the end of the (elevated) line. I forget whether that
killed any people or not.
The fact that we're considering automating cars before trains is just, well, surreal.
There's a lot more going on in a railroad environment
than you think there is.
So why the middleman?
Sun kinks are where the rail expands in the heat far enough that it can't take the stress in compression, and bends off to the side. The ties keep it in gauge, but there's suddenly a curve off to the side and back where there wasn't one before. That curve was not engineered for the track speed limit on that segment; it wasn't engineered at all.
Pull-aparts are where the steel contracts in the cold beyond the tensile strength of the steel to hold, and you get a gap in the rail. These can be (sometimes) detected electrically, by continuity. But how big a gap is it? Where is it, exactly? (Yes, you could figure it out with a time-domain reflectometer.) Can a train safely pass it? At what speed? Well, you need someone to go there and look at it to find out.
> > > It's not going anywhere it didn't go before, and it has no business going 1 MPH faster or slower past any given point on the track than it did the last time!
> > Slower trains ahead of it.
> God, I hope the people working on self-driving cars don't make the mistake of overlooking something that obvious.
Of course. But responding to it in a way that is optimal for the train is not simple. You have to take into account the speed of the previous train, the grade, the characteristics of your own train, and maybe even the weather.
Look, that can all be programmed. But it's not nearly as brain-dead simple as you make it sound.
The ruggedness required of railroad lineside components is very high. They have to resist rain, snow, ice, flooding, hurricanes, vandalism, snowplows, and the machine that replaces the track ballast.[1]
There's no reason the Northeast Corridor shouldn't have had PTC years ago, though. That's a busy line, and since it's electrified it has lots of wayside equipment already. There's resistance from the American Association of Railroads about equipping long freight lines out west and in the south, some of which don't have much traffic. That doesn't apply to the Northeast Corridor.
Speed limit enforcement isn't new to railroading. Many subway systems, including NYC's, have had it for many decades. It's crude, based on timers between signals, but it works. Subways tend to have so many short signal blocks that block-based speed control works reasonably well. Above-ground lines have much longer blocks. Freight rail in open country can go miles between signals.
Secondly, the approach that rail takes all over the world is to have highly interlocked fail-safe systems. Refer to safety integrity levels. [1] Track permission systems operate at SIL 4. It's EXTREMELY hard to 'write an app' that starts ticking the SIL boxes. The GEs of the world sink an incredible amount of money into automating train control and train driving. Still, it comes slowly because of the sheer complexity of hammering out every single corner case.
What is so complex about this? A car has a similar system: the gas peddle. Stop pressing it with your conscious foot, and the car will slow down. The difference is that a car MUST have appropriate steering... the train doesnt.
In the case of Waterfall, the driver had 2 dead-man switches he could use - 1) the throttle handle had to be held against a spring at a small rotation, or 2) a bar on the floor could be depressed. You had to do 1 of these things, the idea being that you prevent wrist or foot cramping by allowing the driver to alternate between the two. Failure to do either triggers an emergency brake.
It turns out that this driver was fat enough that when he had a heart attack, his leg was able to depress the pedal enough to hold the emergency system off. Thus, the dead-man's system never triggered with a whole lot of dead man in the driver's seat.
I can't quite remember the specifics of the system at Waterfall, but one method to combat this is to require the pedal to be held halfway between released and fully depressed. The idea being that a dead leg would fully depress the pedal so that would trigger a brake, and a fully released pedal would also trigger a brake. I don't know if they had that system but certainly that's one approach used in rail.
Either way, the problem is equally possible in cars. If you lose consciousness and your foot goes limp, a heavy enough leg will be able to hold the pedal down a bit depending on where it's positioned relative to the pedal and the leverage it has on the floor.
The other major system I'm familiar with for ensuring drivers are alive at the helm is called 'vigilance'. The way it works is that periodically, a light starts flashing on the dash and the driver has to acknowledge that. If they do not, a buzzer alarm starts sounding. If they still don't acknowledge it, the train brakes apply and the driver is assumed incapacitated. Let me tell you some stories of my involvement in it.
When we first started, we had a simple vigi system. Every 30 seconds or so (for example), the driver would press a button. Ok cool. Except that then drivers became so hard-wired to pressing the button every 30 seconds that we were having instances of drivers falling asleep/dozing off and still pressing the button right on every 30 seconds because it was so ingrained into them that it was literally a subconscious action.
So we introduced random-timing vigilance, where the time varies 30-60 seconds (for example) and you could only acknowledge it within a small period of time once the light started flashing. Again, drivers started falling asleep/semi asleep and would hit it as soon as the alarm buzzed, each and every time.
So we introduced random-timing, task-linked vigilance and that finally broke the back of the problem. Now, the driver has to press a button, or turn a knob, or do a number of different activities and they must do that randomly-chosen activity, at a randomly-chosen time, for them to acknowledge their consciousness. It was only at that point that we finally nailed out driver alertness.
My point is that human-machine interfaces are really difficult to hammer out edge-cases in. Human behaviour is tough to deal with programmatically.
[1]: https://en.wikipedia.org/wiki/Waterfall_rail_accident [2]: https://en.wikipedia.org/wiki/Dead_man's_switch#Vigilance_co...
they look like this: https://upload.wikimedia.org/wikipedia/commons/thumb/2/2f/Tp...
the wikipedia page has more details: https://en.wikipedia.org/wiki/Train_Protection_%26_Warning_S...
there's a more expensive system called ATP that is a lot more complicated (and had a limited rollout), and ECTS is coming...
This is the kind of thing which autonomous-driving skeptics need to keep in mind when they worry about 'how will you stop people from continually stepping out in front of self driving cars to stop them', or 'how will you stop people from jamming your lidar sensors?'
How do trains stop people from interfering with these safety systems? They don't - the fact that interfering with the safe operation of a train is dangerous and subject to huge legal consequences is what stops people from doing it. Same applies to your worries about car technology. What stops people interfering with lidar? The fact that most people are not psychopaths, and they would probably go to prison if they did.
In the NE corridor, everything is of course fully signalled, but installing additional wayside equipment such as for PTC is a huge project over many miles of rail, even in relatively small areas. Solar-powered radio equipment has driven down the cost of installation, but not by as much as you might think. A big part of the high cost is the engineering requirements of the federal railway administration, which are (for good reasons) extremely strict and require proven high reliability.
This reliability must apply everywhere. GPS availability can be iffy under a number of circumstances, most obviously tunnels. There needs to be some non-GPS method of positioning trains in most systems. An example which the HN community will be relatively familiar with is the BART, which features automated train control. BART trains position themselves (and receive speedcodes for central control) via a continuous antenna strip mounted to the safety cover of the third rail. If you inspect the third rail across from a platform you will see it, as well as occasional cables connecting to the trackside control equipment. Installing this sort of thing over miles gets very costly!
The closest analogy to what you are describing is a product called GE Trip Optimizer that uses information about the route and train consist to automatically control throttle for fuel saving purposes. Trip Optimizer does not meet requirements for a safety system, though, and so the engineer is always permitted to override it (and must if any unusual circumstances are encountered), and the engineer must manually account for signals. To be a full PTC system it would still need quite a bit more, most notably reliable communication with signals (better than current cab signal systems).
There are sub-PTC safety systems available, such as train stop devices (which can be rigged for overspeed protection). These are still expensive to install though and at this point most everyone wants to go directly to PTC, which provides much greater protection.
PTC is more than GPS. Much more than that:
1) which track is the train on? GPS off by a few meters 1 way or the other means a different track.
2) What are the switch settings ahead?
3) Is there a train stopped ahead?
4) Is there any obstruction ( i.e. rock fall )?
5) Are the crossing gates ahead properly functioning?
6) Are there vehicles across the crossing ahead?
7) What are the normal speed restrictions in place?
8) Are there maintenance workers ahead?
9) Are there temporary speed restrictions in place because of tracks needing repair?
10) What is the mass of the train? Heavier trains = greater stopping distance.
11) What is the track surface - leaves in the fall can create a biofilm that increases stopping distance.
12) What is the cargo - some cargo requires more gradual deceleration - bottles of wine anyone?
13) What about tunnels?
14) What about mountainous terrain with poor line of sight to GPS satellites?
15) What about signals that may interfere with a GPS fix?
16) What about going through cities with buildings and in trenches?
Expanding on a few additional points:
"Where is the train in front of this train"?
a) Its not enough to know where the locomotive is: some freight trains can be 2 miles long. So if the train in front is 2 miles ahead but is a passenger train - no problem. A freight train? Big problem.
b) Is the train ahead on a siding that the current train will not hit because the switch is thrown to transfer to another track?
"What is the allowed speed?"
a) Is the train going to take a speed restricted curve?
b) Or continuing straight at a higher speed?
c) How fast can the train decelerate - freight is slower than passenger trains.
In a car its annoying -but having a train get confused and go into an emergency stop - that is something else.
This is not a simple problem.
Then throw in all the systems that need to interact and function correctly, have good failsafes, etc.
There is a reason why trains need humans driving them!
Even countries like China with their CTCS use it on modern rail lines.
One of the problems is that you can't really use GPS for location awareness because it can be down without notice and is not available in tunnels. Maybe that restriction will be lifted one day. But there are proven solutions, the US is just too stingy to buy them.
But they probably waited for the next train.
Whoever threw that rock at this train is a mass murderer and should be treated as such.
The operators hate it, and have raised concerns about safety. The quality of human vision, related to both resolution and more importantly dynamic range, is much, much better than any extant camera and display system (especially affordable ones). The system you propose simply wouldn't allow the operators to see well enough, even with very expensive equipment used.
What I found notable was that two months (March vs. May) prior to the accident, the "optimal" break time for train engineers between runs was reduced to 90 mins from about 2.5 hours. The union had protested this change, but to no avail.
If the train the engineer had come in late for any reason, the break could be less than 90 minutes.
In my view, it was certainly unwise to have made this shortening of break time for engineers before the completion of PTC on the line (it at all).
The article also said that Amtrak declined to speak about the engineer's schedule that day.
There could have been other contributing factors (rock, tough schedule), but it seems likely that their severity will not be known -- the information just is not there.
Surely you would concede that the right course of action here is not obvious?
Sadly, he will not be, because the company needs a scapegoat to cover their lack of adopting the technological safety system that can mitigate the human errors that are inherent in the current system.
If he never drives a train again, every single manager in his chain should be fired--including the CEO as they made the choices to set the system up this way.
They do build a narrative around the driver to make him more human and help the reader relate, but for everything else, if I wanted to read a narrative I'd pick up a novel.
The article keeps mentioning the difficult tasks of operating the train -- obey every speed limit sign, every trackside control, speed up here, slow down there. But it doesn't illustrate how these demands are different from the demands placed on the operators of other vehicles. If anything, it seems tractor trailer and bus driver schedules are far more demanding, and they have even more things to look out for while operating their vehicles.
On the side of the difficulties of operating a train, I can see how the endless line of tracks unfurling in front of you can be mesmerizing/tiring (like driving in a snowstorm), and how the 'relative' safety of being secured to tracks can lull you into a false sense of security on stretches where speed changes are not required. Furthermore, of course, the demands of keeping a train on the right set of tracks through various switches can be difficult, because trucks don't face the same risk of head-on collisions with no ability to stop or veer off course at the last second.
Still, without knowing anything about the difficulty of operating the train controls themselves, I find myself wanting for more information to illustrate the unusual demands placed on train operators that are not placed on other long-haul motor vehicle operators. I don't dispute that it's a demanding job, and the consequences greater than those of crashing a tractor trailer, but I'm unable to understand how without more information.
I hadn't thought about it in terms of cycle time and 'tending' as you mention. You're right that having to plan things ahead, and watching the consequences of your earlier actions unfold slowly can be quite stressful. I imagine it also demands much more in terms of multi-tasking because you can't just respond to an immediate need, you need to keep more 'balls in the air' at a given point in time because of how slowly the controls respond. Excellent point, thank you.
--
I read some of the accident reports from the British RAIB, since they're often interesting. It's hardly ever one failure, even for something that seems straightforward. Some of the reports show charts of management structures, since many problems come down to organizational mismanagement — the safety equipment exists, but perhaps wasn't maintained, or a fault wasn't repaired soon enough. By doing 50-page investigations into accidents (or near-misses) with no injuries, hopefully serious accidents will be avoided — and it seems to work, I think it's the safest railway network in the world.
List of all publications: https://www.gov.uk/government/collections/catalogue-of-inves...
Recent example (PDF) https://www.gov.uk/government/uploads/system/uploads/attachm... — a 49 page report for an accident with no injuries.
Even trams, much smaller than trains, require quite a bit of stopping room. Rails are so much more efficient and carry a ton more passengers.
It's sad the American train infrastructure is in such sorry shape. European rails are an essential form of travel, and even their oldest stock have these basic safety features (although they don't help if they're turned off; like in that recent high speed French wreck on its final test run).
They have between 2 and 4 tracks on that corridor and they dont necessarily stay on the same one during the entire trip. You need to make sure you are on the correct track.
You have to radio in at specific markers to let the controller know where you are. If you fail to radio in, they might assume you're AWOL and order an emergency shutdown of neighboring trains.
You have to make sure you have a green light for the particular track you're on at every signal.
Tracks are a scarce resource, if you go too slowly or make a mistake, you are delaying every train behind yours (times the hundreds of people in each one).
You need to use energy efficiently: too much juice and you will grind the wheels, or waste energy by not accelerating at the optimal rate or braking un-necessarily.
You have to control your speed exactly for the particular section of rail you're on.
I don't know how to operate a train. Does pushing a throttle up or down count as a "manoeuvre"? What's "tricky" about this? Am I missing something, or is the author embellishing here?
edit: grammar
You can see what the engineer's station look like in the type of train discussed in the article here:
http://www.eweek.com/mobile/slideshows/amtraks-new-siemens-l...
Looks like there is a combined throttle/braking control on the left side, then (multiple?) brakes on the right.
Also FYI, maneuver isn't an error, it's the American English spelling.
Above the dynamic control on the left you see a small rotary lever - if I'm not mistaken this is the reverser, which simply selects between forward, neutral, and reverse. As a fun fact, this lever pops out and is used as the "key" for the train. For safety reasons, the engineer removes it when they leave the cab so that it's difficult to get it out of neutral.
The big red button left of the dynamic control is the alerter acknowledge. This is the dead-man protection on locomotives and I suspect may factor into the conclusion on this investigation. When an alarm sounds, the operator has to press that button. The alarm becomes very jarring so it might have brought a confused or unconscious operator back to attention.
I'd expect that trainee engineers are trained on specific routes. Whereas a car or truck driver would be expected to operate safely on roads they've never encountered before, this should not be the case for a passenger train engineer. So the difficulty would be doubly embellished.
It appears to me that the most difficult part about driving a train is remaining alert and sober, absorbing and executing the restrictions on the track, and doing so confidently well in advance of turns or restrictions. The theory presented in the article, that he was injured as a result of a rock throw and lost control of the train, seems like as good a conclusion as any. Especially given how unusually dedicated the purported evidence shows him to be.
1) The range of acceleration and deceleration rates available to a train engineer is much, much smaller than you would think. There is simply limited traction and power available and the weight of the full consist is really enormous. This requires planning everything well ahead, which can be difficult in busy areas where you must both anticipate signals and mind an often large number of temporary orders. Train operations tend to sort of happen in slow motion, it's not about fast responses simply because by the time you try to make a fast response the situation is already unrecoverable.
2) Depending on the exact systems in use, speeding up and especially slowing down a train is more complicated than doing so in a vehicle. You have multiple brake systems available (primarily the dynamic and train air brakes), and the most powerful brake system, the air brakes, comes with a lot of tricky caveats as to how strongly you can apply it (mostly related to applying and releasing it too frequently, which can drain the air reserves). There's a lot of great info on this from a former engineer here: http://www.alkrug.vcn.com/rrfacts/brakes.htm
Certainly the author has decided to dramatize the situation. For these reasons, train speeds are established with a wide margin for error (of course not one of an additional 100%+ as in this incident).
If I scroll until the top of the article is at the top of the page, then start reading, I suddenly can't because this inept header just appeared covering the top 10% of the page. Now I have to scroll back up to see the content.
If it had appeared when the massive full-screen image WAS the top 10% it'd've been a perfectly seamless header introduction, but instead they wait until there's something valuable at the top of the page to introduce it.
</gripe>
Now there's no header at all.