> 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.
For understanding the scope of the political problem, the American Society of Civil Engineers has an infrastructure scorecard.
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+
Pennsylvania got a B for Rail in 2014. Michigan got a D for Drinking Water in 2009 (most recent grade).
This seems unnecessarily conspiratorial considering we know for a fact that the US's infrastructure is literally crumbling beneath our cars and trucks.
Not to say that there aren't issues, but "crumbling US infrastructure" has been an on-again off-again news story for literally decades during which time we've had periods like the stimulus package for "shovel-ready" projects. I suspect infrastructure spending, especially in a country as large as the US, is essentially an unlimited sinkhole.
But then fix the sinkhole. Regionalize it, manage it better, change the incentives. I don't know what the answers are, but there's a whole host of countries that have great quality roads, bridges, and public transport.
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.
>Michigan got a D for Drinking Water in 2009 (most recent grade).
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.
Reportedly, the P.T.C. system had already been scheduled for a 2015 installation. This accident is likely speeding up the installation on other tracks, but I'm not certain that the Northeast Corridor really got this upgrade much faster simply because of this accident.
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.
Can I ask a stupid(?) question: So this Positive train control system seems super complicated. Dedicated radio frequencies, track signal loops, and so on. And all this complexity has been holding it up for years...
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?
> 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.
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.
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.
Driving a train, with multiple connected bodies together, is a fair whack different to driving a car. You have to forecast your decisions a lot more lest you introduce some nasty dynamics that can absolutely cause derailment (i.e.: excessive run-in) if extremely bad.
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.
How does the train know where it is? Remember, Amtrak runs some locomotives that are decades old. It's not like there is a "train's computer" equipped with GPS to know where it is.
Usually, by communicating with RFID devices that sit between the rails. Most of these require no external power or connections; they just report their location. Some have connections to the signal system and report the status of signals and switches ahead.
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.
Steam trains in Europe¹ — used for tourism etc — are retrofitted with the necessary safety equipment. Otherwise they aren't allowed on normal railways, and will be restricted to running at low speed on entirely private lines.
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.
Well the GPS would be the part you add during the retrofit. It's not like they're that expensive anymore. Like someone1234 was saying, this seems like a problem that could be solved (at least as a prototype) by a smartphone app with a database of speed limits. Where's the complexity that makes that unfeasible?
There's this thing called GPS. It would cost about $100 to have the train "know" where it is. I don't understand this argument at all.
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.
GPS, especially inexpensive GPS, is widely considered unsuitable for life-safety applications, for a variety of reasons. The bottom line is that it is not accurate or reliable enough. This is why all commercial uses of GPS have a backup mechanism of some sort, and indeed most navigation is far less reliant on GPS than people believe (e.g. airplanes continue to make extensive use of VOR and ILS). Ships at sea are perhaps the only environment in which satellite positioning is sometimes relied on exclusively, and of course as soon as they are near any other object (land, another ship) they rely on visual navigation for safety.
The problem with the rail network is figuring out this backup system.
GPS, especially inexpensive GPS, is widely considered unsuitable for life-safety applications, for a variety of reasons.
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.
Something unreliable is useless - if it stops the train when there's no need, it will cause delays and annoy passengers. It won't be trusted and the drivers' unions will ensure any fault in driving detected with it had no disciplinary effect. But the politicians won't want to spend more on a useful system after buying GPS.
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"?
Sorry, but I believe it's insanely stupid that things are being done the way they're done, and I believe the arguments that I'm "strawmanning" are part of the reason why.
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.
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.
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.
Me: There's this thing called GPS. It would cost about $100 to have the train "know" where it is.
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?
I apologise - you did say that the controls would cost more than $100. A lot of what you have been saying is fantasy though - for example, that there is no need for a train to be going 1mph faster or slower than the last time. Apparently weather conditions should be ignored?
However, just because I made an error (or even strawmanned) doesn't mean that you're not strawmanning.
> There's this thing called GPS. It would cost about $100 to have the train "know" where it is. I don't understand this argument at all.
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.
If you don't know what track your train's on, your GPS fix is the least of your problems.
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".
No, I don't necessarily expect it to be thoroughly integrated right away. But simply having the GPS system as a secondary sanity check on speed seems worthwhile.
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.
The only way the engineer can possibly know about this in time to do anything about it is to rely on sensors that are already there. Trains can take thousands of feet to stop.
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 the engineer can do what about any of those things, other than watch the carnage unfold from the best seat in the house? Other than report the obstruction to other trains, which again could/should have been automatic, the answer is "Not much."
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.
Trains don't work that way. By the time the engineer sees an obstruction with his own eyes, there will be a violent collision.
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.
God, I hope the people working on self-driving cars don't make the mistake of overlooking something that obvious.
Temperature too hot, so sun kinks are possible.
Not familiar with that phenomenon, but how does the engineer know about it, what's he supposed to do about it, and why is his manual judgment or intervention helpful?
Temperature too low, so pull-aparts are possible.
Same questions.
Too much rain, so a river may have washed out a bridge.
Unless there's an automated network of sensors that tells the engineer about it, some people are going swimming. It's that simple.
Some kind of event right next to the tracks, so go slow
and watch for people where they shouldn't be.
In the aviation business, this is handled by issuing what's called a "NOTAM" (notice to airmen.) Automate them.
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.
How about:
while (maintenance_scheduled_nearby() ||
movement_detected_nearby())
{
speed--;
sound_horn();
}
Disclaimer: system not evaluated for stability. :)
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.
While tragic, isolated events like this won't stop self-driving cars from taking over eventually, nor should they. Same story with trains. The fact is, computers will get better at this stuff over time. Humans won't.
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.
Yes, and very little of it is subject to mitigation in real time, unfortunately. As a train engineer, it's important to know what you're driving into, considering that you might need a mile to stop. And if you do know what you're driving into in time to do something about it, you know it because a computer told you.
So when the train is coming up on something like a car stuck on the track, you're right, the train isn't going to stop in time. What it can do, though, is slow down to the maximum extent possible, to give people in the car time to get a %^^&$# clue and get out of the car. The car's history, but the people might live. That's kind of a big deal.
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.
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.
Have you ever ridden on a train? All sorts of shit happens on the tracks that requires extensive communication with other trains on the corridor. It's not just the same cycle of events repeating every day.
All that's needed is a GPS receiver, a database of GPS coordinates and speed limits, a connection to the brake/throttle to slow the train down if it exceeds those limits, and a manual override button.
No, actually, I haven't, not since I was too young to remember. What would be an example of a situation where it's important to rely on human judgment during changing track conditions?
Children playing on the track ahead. Fallen tree across the tracks. Moist leaves on the rails. Road crossing not clear. Probably a bunch of more nuanced things that someone familiar with driving trains would know. You need a wide array of failsafed sensors to replace a human doing all of these. Certainly more than the $100 you suggest.
Hell, in my state, the electronic comms for trains get adversely affected by caterpillar plagues from time to time.
Children playing on the track ahead. Fallen tree across the tracks.
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.
Not every event that happens uses worst-case data. In any case, while I don't know the actual class of rail where this emergency stop happened, this wiki article[1] suggests that most mainline track in the US is class 4, which allows a max of 80mph for passenger trains.
Out of curiosity, why do you mix metric and imperial in the same context? Stopping distance in metric for a speed in imperial?
British usage is a mess, they were the units I found. I didn't really think about it. I also can no longer find the table of stopping distances I found this morning.
Sure, but at the end of the day - youre talking about ONE feature "Slow/stop train when not assured that the eng is actively at the helm"?? Arent you?
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.
There was a derailment in Australia called the Waterfall derailment [1]. It occurred because the driver had a heart attack and was responsible for 7 deaths (a miracle it was so low, honestly). The root cause was the failure of the dead-man's switch.
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.
Three-stage deadman's switches are also emerging in some industrial equipment because of research finding that people will often react to surprising or alarming situations by tightening their grip, rather than loosening it. These "enabling switches" must be held halfway closed for machinery to move, so that dropping them or panicking should stop the mechanism.
GPS works everywhere and rigging a speed limiting controller to an existing throttle is probably a day's job for an expert hacker. A year's worth of work should be more than enough time to produce, test, and deploy such a system. What is the risk again?
The requirements of PTC go beyond anything a car's navigation system has to, most notably maintaining separation between trains: also, unlike a car's navigation system, because it's a system there to ensure safety rather than provide assistance to the driver, the system has far higher requirements for failing safe. As far as I'm aware, proceeding without movement authority is a far more common cause of rail accidents than overspeed, hence why systems have traditionally been mostly concerned with separation and movement authority rather than speed.
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.
The simple answer: Trains can't stop quickly, and can't switch tracks easily.
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
"(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.
Still, someone in junior high can do the math to figure out the solution given speed and location of each train. My guess is that no one knows the location or the speed of the train because we don't want to spend the money. Of course, it'll be extremely expensive to solve this because of how Amtrak is managed.
Yeah, someone programmed the Uber app with junior high math to show you where your driver is. But I regularly see the driver pull up when the Uber app shows him still a couple of blocks away. I wouldn't Uber's app controlling my fricking train.
the UK's railways have a cheap and simple solution: two transmitters at different frequencies inside the track, the distance between them controls the maximum speed.
if the train detects the second too quickly after it detects first it applies the brakes.
That's a very elegant solution; has the disadvantage that its failure mode is not safe - if the train fails to detect a signal at all, then it will just continue at whatever speed it likes. And of course, like a lot of physical engineering solutions, it's not built to be secure against malicious actors. Someone who broadcast fake signals could slow a train down - or confuse it into ignoring the real signals.
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.
Train control is not super complicated, it has been deployed in various forms in Europe for decades. Rail infrastructure providers offer turn-key solutions based on common standards like ETCS. It is expensive due to a lot of hardware that needs to be deployed, but that's it.
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.
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!
One of the big problems with rolling out infrastructural upgrades to the US train network is, in general, its size. Consider that there are still substantial sections of freight rail in the country that are what is referred to as "dark territory," meaning that there is no signally installed. Additionally, there is usually no radio or cellular coverage in these areas. Train motion in these areas is typically governed via track warrants, meaning that an engineer must obtain written permission from a dispatcher before entering the area (and only one train is given this permission at a time).
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.
The GPS owners (US DOD) have the prerogative to turn it off, or at least impair its resolution significantly. without a lot of warning. So a backup system is necessary. But, it sounds like the engineer's knowledge of the route is that backup.
When do they shut off (actually go to lower resolution) the GPS? When there's a war (invasion of Iraq, for example). Or when there's a bottleneck for two long in the process of launching replacement GPS satellites. You want to stop all the trains if one of those occurs? Until the military action is over or there's a successful satellite launch? Get outta here.
Seems like that would be trivially solved by using dead reckoning in tunnels. You know the exact path of the tunnel, you know when you enter it, and you can count wheel revolutions to see exactly how far you've gone within it. But perhaps I'm missing something that makes this harder.
In principle you are right, but precision is an issue: the train control system needs to know the position in the centimeter range. Counting wheel revolutions is notoriously unprecise because as the wheels wear down, they rotate faster.
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.
I don't see why tunnels would be an issue. If the app has been tracking the object for a while it can calculate projected speed, and as it loses the GPS signal it can use an internal clock to continue to estimate the train's current location.
Navigation systems already do this for signal losses (and to save battery).
This business of mischief-makers throwing rocks at trains is a real thing and has been for a long time. In 1974, in rural coastal Connecticut, I was on the way to a beach, on a footbridge over the Eastern Corridor tracks. There were two middle-school-age boys. One had a brick in hand, and the other said "hey, here it comes." I intervened and prevented that brick from hitting the engineer's windshield.
Yeah, I think some cracking down on this might be a good idea, even if it means blanketing hundreds of miles of track with lights and surveillance cameras.
Whoever threw that rock at this train is a mass murderer and should be treated as such.
Here's probably a better idea: get rid of the windshields; replace them with steel plates. Put some cameras on the roof and monitors on the inside where the windshields were. You could even use IR-sensitive cameras at night, to better spot people on the tracks.
There is some use of cameras instead of windows on the train involved - instead of the conventional wing mirrors, it has rearward-facing cameras for watching the platform.
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.
Part of my work involves healthcare patient safety -- principles learned from aircraft, nuclear power, oil & gas, safety, etc.
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).
If you read more of the article, it says that the engineer came in about 30 minutes late due to an issue with a computer system before leaving New York.
The article also said that Amtrak declined to speak about the engineer's schedule that day.
Forgive me for my ignorance, but wouldn't adding a few balises to the track (https://en.wikipedia.org/wiki/Balise), and the matching receiver in the trains, be enough to limit the train speed to what the track allows? Or would even a simple system with fixed balises need FCC approval?
The political will has always seemed to be to go for a better solution than a few balises, probably in part given there is so much fight to get anything that installing some balises would likely hold back introducing anything better in the near future.
Forgiven, three times :). It has been rolled out in France (KVB), Germany (LZB) and Spain (ASFA) for decades. And it's considered outdated stuff. Now everyone switches to ERTMS.
I was on a Northeast Corridor trip once when the train was struck from the side by a rock. It sounded like a gunshot went off inside the car-- everyone jumped and there were more than a few shouts. I can imagine being hit head-on by a rock at night would be enough to distract an engineer for a few critical minutes. What a shame.
If this article is completely true, it’s sad to hear he would never pilot a train again even if exonerated. That sounds like how teachers are treated if a student accuses them of impropriety and their careers are over even if they are innocent. Is that a uniquely American thing?
Your analogy is not really valid. Although the NTSB is not talking, the cause is reported to be "loss of situational awareness". In essence, the conductor was in some degree at fault because he was controlling the speed and the train was going 105mph instead of 55mph.
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?
Actually, the right course of action is perfectly obvious--he should be restored to driving trains. No other train engineer has been scrutinized so carefully, and he came out with flying colors.
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.
I feel like that article had a massive amount of fluff. I understand trying to build a narrative, but the article felt like one of those modern sensationalized documentaries where they take 45 minutes to explain a 10 minute thing (e.g. everything on the History channel).
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.
Can someone well-versed in train operation help explain the difference between operating a train on these kinds of routes and schedules and, say, operating a tractor-trailer or bus?
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.
Trains are not buses. They are massive. A train running at full til can take several kilometres to slow down, and it most slow down gradually. The emergency air brake is a last resort and can cause derailment itself.
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).
One principle difference is that the rails and momentum dictate where you go. All you can do is gradually speed up and gradually slow down.
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 suppose buses are similar, but at least for long haul truck drivers you have much more freedom in the way things are going. Need to take a bathroom break? Pull over at the next rest area? Hungry? Stop and get food. You can't exactly pull a train over at the next gas station if you need to grab a coffee or some Advil. That's a huge difference right there.
I'd guess that the amount of momentum in a quickly moving train makes any changes take a lot longer to take place and mistakes harder to address in time. You don't just stamp the brakes to stop or push the accelerator to speed up. The cycle time on system changes requires "tending".
Others also pointed out trains are big and heavy, which I thought of more in terms of an advantage (doesn't exactly speed up all that quickly) or neutral in terms of impact on the conductor (if it crashes, yes, it's a big deal, but assuming it doesn't, it's not).
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 think planning ahead is the main thing, resulting from the huge momentum of the train and the low friction with the track. It's essential to stop in the correct places, but it's also necessary to keep accelerations smooth (we don't want all the wagons bumping together, or slipping wheels), including up and downhill. Driving must also be efficient, and with good planning it's easily possible to coast many miles on a slight gradient. (Did everyone just get off the train at the stadium? Then the braking distance will change. Except it's raining now, so it's longer.) Acknowledge every signal, and run to time — being early means being stopped, which is wasteful (and annoying for passengers, if this is a passenger train), being late means delaying other trains.
--
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.
> It was a tricky series of maneuvers for even the most experienced engineer: speed up out of North Philadelphia Station; slow for a gradual curve at North Second Street; throttle open again for the straightaway, where the speed limit is 70 m.p.h.; and dump speed for the sharp 50-m.p.h. curve.
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?
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).
A train, or even just a single locomotive, has a hell of a lot of momentum, and steel wheels on steel rails don't offer a whole lot of braking capacity for the mass they are carrying. Stops and target speeds must be anticipated well in advance.
I'm similarly ignorant on all the intricacies of driving a train, but my understanding is that the coupled nature of a train vs. a rigid body make the dynamics more difficult to deal with than you might imagine. That being said, I don't know how much that affects the difficulty of the operator at this point or whether that's all worked out in the train's control software.
You can see what the engineer's station look like in the type of train discussed in the article here:
Yes, if I'm correct you are seeing the dynamic control on the left (forward for acceleration, reverse for dynamic braking) and the air brakes on the right - the big left handle is the train brake (sends the change down the brake line to the cars as well) and the smaller right handle is the locomotive-only brake (often used to get slow down the loco first so the coupler slack will get taken up and prevent bumping the passengers around or damaging equipment). The little LCD display shows some calculations to help the engineer make good braking decisions.
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 imagine that when operating a ~400 ton machine any operation is at least slightly more complicated than just pushing a lever. Especially when combined into a series in a short period of time at night in poor lighting while having rocks thrown at your windshield.
I think the author is embellishing. While it may be trickier than driving a truck, this is not on the same scale of difficulty as operating a large freight train, where the operator needs to consider where the back of the train is in relation to the locomotive, nor as difficult as operating an airliner, where a momentary navigational error could put the entire airship underground in a matter of seconds.
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.
Web designers - Take note of the NYTimes.com header that appears after you scroll down to the content. These dynamically-appearing headers are a good idea, but nobody seems to get the nuance right.
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.
Most simply, just add a larger space between the image and text for when it attaches. There are better ways to approach it, but this is pretty easily avoided.
> 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.