I have used this system for about 5 years, it has improved, but it really far from perfect, a well trained engineer can do a lot better job with running a train efficiently, the leader system gets confused a lot with grades, it does too many throttle suggestions, I do not know how they actually measure fuel savings. The parts I like are the route maps, info on grades, speed limit listings, possible projected speeds( though sometimes it is wrong on those). The whole driverless train thing has a lot further to go than many will admit. The leader system also has issues in areas with complex multiple routes and directions. A side note: PTC is really going to be interesting to watch when it is fully implemented.
Wait and see. Firemen were once “indispensible” also. The trend throughout industries of all sorts has been for many years and continues to be automation, which is the primary reason for both job losses and increases in productivity.
Disclaimer: In no way is it my intention to cast aspersions towards today’s Engineers, as I am certain they have their own difficulties running today’s huge trains. But running a train with high-horsepower, high-adhesion locomotives with fantastic wheel-slip control, quiet cabs, and high-tech electronics is, at least using just those criteria, much easier. Of course, today the trains are much longer and heavier, with distributed power to contend with, and Trainmasters and their ilk waiting around every corner to try and catch a rule violation. How today’s Engineers manage to keep everything together (considering the lack of extensive hands-on experience) amazes me.
Be that as it may, back ‘in the day’ the firemen were indeed “indespensable”, in the same way an airline co-pilot is. Watching and learning was the only was a person could become proficient in the trade. “Hands on” was the only way to learn what was then an extremely difficult craft, at least to learn it well enough to not be feared by the Conductor and rear brakeman.
Engineers had to contend with unreliable power, no radio communication, AB freight car brakes, friction bearings, no dynamics, 24RL and 6BL brake valves in the locomotive. Back then, if the Conductor needed to communicate with the Engineer, the only way was to pull the air and start walking.
Hotbox detectors used wayside signals to indicate to the Engineer the condition of his train. And if the signal was against you, you had to seek out the lineside phone in order to contact the dispatcher (good luck finding it in dense fog and/or heavy snow, especially at
With the size of todays trains, if there was still a caboose, slack action would be lethal.
Today’s railroads have done away with all the positions that were once the apprentice to learning the craft. Because of two man road crews, the Conductors position (if they get along with the particular engineer) may still get some apprentice time in their forced path to becoming a Engineer.
Was it as common back when firemen and engineers belonged to separate unions for firemen to become engineers?
The path to being an engineer almost always required being a fireman first. Some BLE contracts allowed hiring engineers under certain conditions. (Although a “hired” engineer almost had to have been a fireman somewhere at sometime.) A RI agreement I have allows engineers to be hired at a ratio to those being promoted depending on how long a person was required to fire on any specific seniority district. Example less than three years required to fire, all engineers will be hired. At the other end, on districts requiring to fire 8 or more years, all engineers will be promoted. There’s a ratio for in between, but I don’t have time to give all of them.
While you may have been required to belong to one of the recognized unions, it wasn’t necessarily the one that held your contract or the craft you were working. That’s still true today. There are engineers who belong to SMART-TD (former UTU) and conductors who belong to the BLET.
Jeff
Back about 45 years ago, when some trains had an engineer, a brakeman, and a conductor, I wonder what provision was made for a man in road service to learn the work of an engineer. I never thought to ask any of the men whom I knew.
Thanks, Jeff. It didn’t occur to me that there could be crossover between unions and crafts.
.
Quote from the link:
Developed by New York Air Brake / Train Dynamic Systems Division, LEADER has provided 30,000,000 gallons of fuel savings to railroads in North America, Australia, Mexico, and Brazil. Bill Sturtz, General Manager, New York Air Brake / Train Dynamic Systems Division announced, “It is a testament to LEADER’s ability to correctly manage in-train forces that over 125,000,000 miles and more than 800,000 trips our system has never broken a train.”
http://www.businesswire.com/news/home/20131101005905/en/York-Air-Brake-LEADER®-Users-Share-Data
LEADER (or GE’s Trip Optimizer) has no control over air brake operation. It can prompt to apply and release air brakes, but only has actual control (auto throttle version) of throttle/dynamic brake.
That is one of the things I don’t like about it that I think will get someone in trouble. Even with the system suspended, it still prompts air brake applications/releases. It doesn’t recognize signals. Coming up to a stop signal with the system suspended (manual mode) and with air set, it will still prompt to release the air brakes. There are places where if you do, you might not be able to immediately reapply to get stopped in time with a heavy train. They want us to immediately respond to LEADER prompts. One day one of us trained monkeys, without thinking, being conditioned to respond will follow the prompt and release the air with dire consequences.
I should note, the current ads appearing in Trains are for the auto throttle version of LEADER. The first version has no control over anything. It just prompts the engineer to change throttle/dynamic brake positions. Auto throttle is better than the first version. Auto Throttle will run DP consists seperately from the lead consist. The first version only prompted for the lead consist and operates under the assumption that any dp consists are in sync mode with the lead.
Jeff
Jeff, I can relate to your pain. Though the technology can improve train handling it is only as good as those who develop the programs/applications/software to do do. The old “GIGO” surely applies in railroading, aviation, and many other areas. As an example, I cite the internet. Has it done anything to simplify our lives or has it added more distractions and the instant availabilty to check news? The latter sounds like a sure bet.
I’m not familiar with train handling appli
They may not be counting every contingency that you mention as a failure of their system when they say, “It is a testament to LEADER’s ability to correctly manage in-train forces that over 125,000,000 miles and more than 800,000 trips our system has never broken a train.”
I am referring things you mention such as malfunctioning locomotives (such as no sand, wheel-slip issues, load dropouts, etc), trainline ‘kickers’, air hose parting on crossings or from debris placed between the rails, train striking a vehicle or person, signal malfunctions (such as dropping from clear to red just as the train approaches).
Today’s rail managements view ‘technology products’ that can be implemented up rank and file workers as being the next best thing to infalible - until it is proven by the rank and file that a product is less than advetised and in many cases absolute junk, then the suppliers get pressed for improvements, refinements and in some cases revised logical decisions.
Rail management tends to believe technology salesmen’s claims when it come to purchasing technology products for the work force. However, when it comes to technology products for Senior Management it is still the ‘we have done it that way all our career and arn’t about to change now’.
I worked for a company that manufactured Avionic equipment and when many products were in the development stage, we had airline pilots come to us to give their input as to what the product should do. Each airline also had input as to what they wanted. And they were ALL DIFFERENT! As a simple example: the device that detects that the plane is in an attitude that is wrong in approaching the ground, has an audible alert to warn the pilot of the situation… you have heard them in movies when a plane is about to crash…
“WHOOP WHOOP PULL UP! WHOOP WHOOP PULL UP!”
is the usual refrain in the movies and on TV… but some change the “WHOOP” to a bell, “DING DING”, others are a klaxon (dunno how to spell that one!). Others use 'TERRAIN TERRAIN" as the spoken words. There were other options for all of those things also.
In addition, some started out at full volume to get the pilot’s attention, then quieted down to just a background annoyance to keep the pilot alert. Some started at low volume and got progressively louder until someone acknowledged it somehow. Others would vary the volume or change the “noise” to keep the pilot’s attention to the problem. Every airline had a slightly different model of the same product. And the audible portion was just the easily detectible differences… the angle of attack and distance from the ground varied amongst different models as well.
NOBODY could agree on what was the correct way to do it.
Heck, I’ve had that problem writing programs for myself - “well, that didn’t work out like I planned…”
I have seen many people attempt to automate bad processes thinking that they would somehow provide different results.
[quote user=“Euclid”]
zardoz
While I’m certainly no Luddite, I find it hard to believe any software could be written that could handle the many variations of tonnage, load/empty distribution, track profile (grade ups and downs, curves), wet rail, snowy rail, leaves on rail, cold temperatures, hot temperatures, malfunctioning locomotives (such as no sand, wheel-slip issues, load dropouts, etc), trainline ‘kickers’, air hose parting on crossings or from debris placed between the rails, train striking a vehicle or person, signal malfunctions (such as dropping from clear to red just as the train approaches); just to name a few.
They may not be counting every contingency that you mention as a failure of their system when they say, “It is a testament to LEADER’s ability to correctly manage in-train forces that over 125,000,000 miles and more than 800,000 trips our system has never broken a train.”
I am referring things you mention such as malfunctioning locomotives (such as no sand, wheel-slip issues, load dropouts, etc), trainline ‘kickers’, air hose parting on crossings or from debris placed between the rails, train striking a vehicle or person, signal malfunctions (such as dropping from clear