Trains.com

Regarding the claims made by NYAB in ad

6715 views
37 replies
1 rating 2 rating 3 rating 4 rating 5 rating
  • Member since
    March 2003
  • From: Central Iowa
  • 6,828 posts
Posted by jeffhergert on Monday, June 19, 2017 8:24 AM

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

  • Member since
    December 2007
  • From: Southeast Michigan
  • 2,983 posts
Posted by Norm48327 on Monday, June 19, 2017 11:33 AM

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

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.

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.

Norm


  • Member since
    January 2014
  • 8,148 posts
Posted by Euclid on Monday, June 19, 2017 12:37 PM

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). 

 

  • Member since
    May 2003
  • From: US
  • 24,958 posts
Posted by BaltACD on Monday, June 19, 2017 12:47 PM

Norm48327
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.

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!

              

  • Member since
    April 2007
  • From: Iowa
  • 3,293 posts
Posted by Semper Vaporo on Monday, June 19, 2017 1:40 PM

 

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.

  • Member since
    December 2001
  • From: Northern New York
  • 24,877 posts
Posted by tree68 on Monday, June 19, 2017 2:08 PM

Semper Vaporo
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".

Heck, I've had that problem writing programs for myself - "well, that didn't work out like I planned...."

LarryWhistling
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...

  • Member since
    July 2008
  • 2,325 posts
Posted by rdamon on Monday, June 19, 2017 2:23 PM
I have seen many people attempt to automate bad processes thinking that they would somehow provide different results.
 
  • Member since
    March 2003
  • From: Central Iowa
  • 6,828 posts
Posted by jeffhergert on Monday, June 19, 2017 9:57 PM

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). 

 

 

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

         

Join our Community!

Our community is FREE to join. To participate you must either login or register for an account.

Search the Community

Newsletter Sign-Up

By signing up you may also receive occasional reader surveys and special offers from Trains magazine.Please view our privacy policy