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.
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.
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.
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. 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." 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.
God, I hope the people working on self-driving cars don't make the mistake of overlooking something that obvious. 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? Same questions. Unless there's an automated network of sensors that tells the engineer about it, some people are going swimming. It's that simple. In the aviation business, this is handled by issuing what's called a "NOTAM" (notice to airmen.) Automate them. How about: Disclaimer: system not evaluated for stability. :) 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.
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 why the middleman?