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 to red just as the train approaches).
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 to red just as the train approaches).
All the energy management systems (LEADER and Trip Optimizer) do is run the train, either by prompting the engineer or directly operating the throttle/dynamic brakes, according to the consist details (engines on-line and their position in the train/loads and empties/tonnage), grade and curvature profile, maximum speeds allowed (which include train type/permanent and temporary restrictions). Neither system knows what the signals (in signal territory) are. They operate as if the signals are all clear. (That's why they're called a "clear block system".) If signals require a train to slow down or stop, the engineer must take manual control. Approaching Form B (work zones) locations, both systems have the engineer take manual control two miles before and one train length after. This is because instructions could require a train to run at reduced speed or even stop before or within the limits.
LEADER is always calculating. It predicts what speed it will be doing at about every quarter mile out to 3 or 4 miles ahead of the train. I think that is what leads at times to some bad train handling. It "looks ahead" a few miles and sees it will be overspeed, so it prompts/auto throttles down. Then it "sees" that it is now underspeed for it's current location, so it prompts/auto throttles up. (Some units are worse than others, even though you would think the system would be uniform over all units. That every equipped engine would operate the same, but they don't.) The worst ones are the ones which want to throttle up/down while starting down a hill. It will prompt or go from power to dynamics, going back and forth. Putting the head end slack in, then letting it roll out. In reporting feed back, I refer to this as playing the train like an accordian. Then, by going back and forth, it lets speed build up to the point that using air is needed. If it had just went into dynamics, stayed in them-increasing as needed, you could've gone down the hill without using air.
As I said, some units are worse than others. From my experience in one difficult spot, two similar trains both using the prompting version. Both trains the same on paper: 135 car loaded coal train, engines 2x1 with the dp at the rear. Tonnage and length almost exactly the same. Following the prompts with both, one went through OK. The other got a knuckle 80 cars deep. I wasn't held responsible because I was following the system. After that break in two, I no longer follow LEADER prompts in that location. It doesn't run a train the same way I would through that spot and after that B-I-T, I don't trust it at that spot.
Jeff
Semper VaporoIn my 40+ years as a computer programmer I was asked many times to write code to make someone's job easier and I learned that I had to do that person's job before I could write anything they could use. I would "job shadow" with them for a month first, then go write some code and then try it out myself to see if it did any good for them. Once I felt like I had it pretty good, I would release it to the people doing that job and brace myself for the onslaught of complaints about how stupid and useless it was. Many iterations later, most of the people involved would be using it, but a few would still be doing it the "old way".
Heck, I've had that problem writing programs for myself - "well, that didn't work out like I planned...."
Larry Resident Microferroequinologist (at least at my house) Everyone goes home; Safety begins with you My Opinion. Standard Disclaimers Apply. No Expiration Date Come ride the rails with me! There's one thing about humility - the moment you think you've got it, you've lost it...
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.
There was another product that controlled the plane in landing and some pilots praised the way it worked and other pilots thought it was the worst way to land a plane (Outside of a crash!, that is).
In my 40+ years as a computer programmer I was asked many times to write code to make someone's job easier and I learned that I had to do that person's job before I could write anything they could use. I would "job shadow" with them for a month first, then go write some code and then try it out myself to see if it did any good for them. Once I felt like I had it pretty good, I would release it to the people doing that job and brace myself for the onslaught of complaints about how stupid and useless it was. Many iterations later, most of the people involved would be using it, but a few would still be doing it the "old way".
Semper Vaporo
Pkgs.
Norm48327Are railroads "behind the power curve" in this respect? [That's an aviation comment about those who let their plane get ahead of themselves.] I suspect the answer is "YES" given the restance to change that appears to be the corporate culture today. "We've always done it that way is the mantra, why should we change? That was the norm in the nineteen fifties and the attitude prevails to this day. I witnessed it when I was young and still see it today. Human nature relies on what people are familiar with. Change is always suspect in some minds and demanded in oters. The resistance to change can be overwhelming at times, yet the urge for change can also be compelling. I'm off my rant. I have respect for those who do their jobs to the best of their ability. Some have been given a "hard row to hoe". They live or die based what they have been tasked to do.
Human nature relies on what people are familiar with. Change is always suspect in some minds and demanded in oters. The resistance to change can be overwhelming at times, yet the urge for change can also be compelling.
I'm off my rant. I have respect for those who do their jobs to the best of their ability. Some have been given a "hard row to hoe". They live or die based what they have been tasked to do.
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'.
Never too old to have a happy childhood!
zardozWhile 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.
jeffhergert 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
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, 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 applications of technology because I've been involved with aviation for a long time. But I suspect those developing those applications have gone through the same learning curve and are getting more proficient in doing so. We, in aviation refer to that as "The school of hard knocks"
Many times their work was suspect and sent "back to the drawing board". Thankfully, the avonics manufacturers have gotten most things right. There will be tweaks in the future to refine programming but airline passengers can take comfort in the fact most aviation apps are enhancing safety.
Are railroads "behind the power curve" in this respect? [That's an aviation comment about those who let their plane get ahead of themselves.] I suspect the answer is "YES" given the restance to change that appears to be the corporate culture today. "We've always done it that way is the mantra, why should we change? That was the norm in the nineteen fifties and the attitude prevails to this day. I witnessed it when I was young and still see it today.
Norm
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%C2%AE-Users-Share-Data
.
jeffhergertWhile 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.
Thanks, Jeff. It didn't occur to me that there could be crossover between unions and crafts.
_____________
"A stranger's just a friend you ain't met yet." --- Dave Gardner
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.
Johnny
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.
BaltACD zardoz But most important was learning the skills necessary to control slack action. We talk now of bad slack control causing lading damage and breaking the train, but back then slack action could (and did) cause severe injuries to anyone riding in the caboose. Indespensible indeed! 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.
zardoz But most important was learning the skills necessary to control slack action. We talk now of bad slack control causing lading damage and breaking the train, but back then slack action could (and did) cause severe injuries to anyone riding in the caboose. Indespensible indeed!
Indespensible indeed!
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?
zardozBut most important was learning the skills necessary to control slack action. We talk now of bad slack control causing lading damage and breaking the train, but back then slack action could (and did) cause severe injuries to anyone riding in the caboose. Indespensible indeed!
schlimm 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.
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 night. And once the info was received, thus began the long walk back to fix it. And woe to the crew if the head-end was around a curve 3/4 miles ahead. I won't even go into the fun we had resulting from a break-in-two.
But most important was learning the skills necessary to control slack action. We talk now of bad slack control causing lading damage and breaking the train, but back then slack action could (and did) cause severe injuries to anyone riding in the caboose.
zardoz schlimm Electronic braking that has been discussed on here before is supposed to reduce slack problems considerably. I think an engineer's job is hard but I also think much of it can and will be automated within the next 10-15 years, at least on mainlines. Yup. And when we see a train, will we be waving at C3PO at the controls? And will he wave back?
schlimm Electronic braking that has been discussed on here before is supposed to reduce slack problems considerably. I think an engineer's job is hard but I also think much of it can and will be automated within the next 10-15 years, at least on mainlines.
Electronic braking that has been discussed on here before is supposed to reduce slack problems considerably. I think an engineer's job is hard but I also think much of it can and will be automated within the next 10-15 years, at least on mainlines.
Yup.
And when we see a train, will we be waving at C3PO at the controls?
And will he wave back?
C&NW, CA&E, MILW, CGW and IC fan
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.
James Sanchez
erikem . . . A long freight train is a whole different beast as it isn't a rigid body with respect to curves (horizontal AND vertical) and slack action. With regards to the latter, it is very easy to break the train with improper control inputs, either through slack action or stringlining (tank car of metam sodium?). . . .
Even then, there's an element of 'dashpot' in the cars because the draft gear allows some motion with varying degrees of resistance. Compare to the slack between the coupler knuckles, which is pretty 'loose' as that space opens and closes. But it's better now that the Hydra-Cushion cars aren't so prevalent . . .
As to engineer proficiency: One of Malcolm Gladwell's books had a chapter on how the best correlation with aircraft crashes was the culture of the crew, not weather or anything like that. As I recall, the US pilots are the safest because they're not afraid to challenge something that seems not right to them, whether it's a wrong decision by the command pilot or a bad situation. Jeff's recounting of how he observes and overrides the system seems to be of like kind.
- PDN.
Buslist Now all we need is uniform brake valves and draft gear. Tests have shown up to 100% stopping distance variation based on valve and rigging type. This issue is one of the bugaboos with PTC enforcement curves.
Now all we need is uniform brake valves and draft gear. Tests have shown up to 100% stopping distance variation based on valve and rigging type. This issue is one of the bugaboos with PTC enforcement curves.
Murhpeys Law- There is no such thing as fail safe
schlimm erikem schlimm I suspect much the same was said about autopilots on aircraft. Developing an autopilot is a much simpler problem than developing control software for a long freight train. An airplane can be treated (mostly) as a rigid body with relatively simple flight dynamiics. As long as the plane is under maneuvering speed, flight control inputs are unlikely to break the airframe. The impetus for autopilots came from reducing the workload on the pilots, or in the case of high performance aircraft were stability augmentation systems that responded much faster than any human could. A long freight train is a whole different beast as it isn't a rigid body with respect to curves (horizontal AND vertical) and slack action. With regards to the latter, it is very easy to break the train with improper control inputs, either through slack action or stringlining (tank car of metam sodium?). In addition, the varations in train makeup will make for very significant changes in train dynamics. That said, even very recent autopilots have had problems dealing with unexpected events such as icing of the pitot tubes. (omitting long rant on control yokes versus side sticks on transport aircraft) You are the engineering guy, but surely weather, velocity, acceleration, and horizontal and vertical changes are complicating factors not seen on trains. In the history of science and technology, generally certain developments happened earlier because they are simpler/easier.
erikem schlimm I suspect much the same was said about autopilots on aircraft. Developing an autopilot is a much simpler problem than developing control software for a long freight train. An airplane can be treated (mostly) as a rigid body with relatively simple flight dynamiics. As long as the plane is under maneuvering speed, flight control inputs are unlikely to break the airframe. The impetus for autopilots came from reducing the workload on the pilots, or in the case of high performance aircraft were stability augmentation systems that responded much faster than any human could. A long freight train is a whole different beast as it isn't a rigid body with respect to curves (horizontal AND vertical) and slack action. With regards to the latter, it is very easy to break the train with improper control inputs, either through slack action or stringlining (tank car of metam sodium?). In addition, the varations in train makeup will make for very significant changes in train dynamics. That said, even very recent autopilots have had problems dealing with unexpected events such as icing of the pitot tubes. (omitting long rant on control yokes versus side sticks on transport aircraft)
schlimm I suspect much the same was said about autopilots on aircraft.
I suspect much the same was said about autopilots on aircraft.
Developing an autopilot is a much simpler problem than developing control software for a long freight train. An airplane can be treated (mostly) as a rigid body with relatively simple flight dynamiics. As long as the plane is under maneuvering speed, flight control inputs are unlikely to break the airframe. The impetus for autopilots came from reducing the workload on the pilots, or in the case of high performance aircraft were stability augmentation systems that responded much faster than any human could.
A long freight train is a whole different beast as it isn't a rigid body with respect to curves (horizontal AND vertical) and slack action. With regards to the latter, it is very easy to break the train with improper control inputs, either through slack action or stringlining (tank car of metam sodium?). In addition, the varations in train makeup will make for very significant changes in train dynamics.
That said, even very recent autopilots have had problems dealing with unexpected events such as icing of the pitot tubes. (omitting long rant on control yokes versus side sticks on transport aircraft)
You are the engineering guy, but surely weather, velocity, acceleration, and horizontal and vertical changes are complicating factors not seen on trains. In the history of science and technology, generally certain developments happened earlier because they are simpler/easier.
At least it was a photo finish... or an oil painting.
Thanks,Semper Vaporo You forgot Mother-in-law nagging at the rail. Thanks. I completely forgot about her. She did not even show.
Semper Vaporo You forgot Mother-in-law nagging at the rail.
You forgot Mother-in-law nagging at the rail.
Deggesty I believe that if Spike Jones were to play the same piece that Lawrence Welk played, he would apply his talent to the performance. He was unique; who else could describe a horse race as he did--"Cabbage is ahead, Girdle is in the stretch, Tomato is trying to catchup--and it's Hankerchief by a nose!" He was not inept. Edited to correct spelling mistakes.
I believe that if Spike Jones were to play the same piece that Lawrence Welk played, he would apply his talent to the performance. He was unique; who else could describe a horse race as he did--"Cabbage is ahead, Girdle is in the stretch, Tomato is trying to catchup--and it's Hankerchief by a nose!" He was not inept.
Edited to correct spelling mistakes.
WARNING: OFF TOPIC RESPONSE!!!!!!
Actually the song you are referring to; Spike Jones manic take on the classic "William Tell Overture", featured narration and lyrics written by City Slickers associate "Professor" Doodles Weaver
https://en.wikipedia.org/wiki/Doodles_Weaver
He was a regular contributor to Jone's radio show and interestingly, the uncle of well known actress Sigourney Weaver..
https://youtu.be/aupQysNpMzk
"I Often Dream of Trains"-From the Album of the Same Name by Robyn Hitchcock
The main issues with weather and autopilots are extreme turbulence (e.g. thunderstorms) and icing. Both are usually dealt with by avoiding them, with the autopilot allowing the pillot(s) to concentrate on naviagting around those conditions. Having said that, icing is the more serious of the weather related issues for autopilots as many aircraft are certified to fly into known icing conditions and that icing WILL change flight dynamics in various unpleasant ways.
Freight trains are also affected by weather, with rain, snow and ice affecting adhesion along with wind affecting train resistance in much more complicated ways than winds aloft affect flying.
Keep in mind that an autopilot is pretty simple device, a couple of gyros coupled to the flight control surfaces to keep the wings and nose level. There's a bit of control theory behind this, with the impetus coming from problems of the interation between the constant speed props and turbochargers on the B-17. A flight management system is a bit more complicated, controlling the throttles, iniating turns, climbs and descents.
To do the train right, every car in the train needs to be modeled.
Our community is FREE to join. To participate you must either login or register for an account.