So it appears UP has developed software to help terminals build trains called Precision Train Builder, or PTB. It suppposedly simulates how a train will handle over any given territory. I guess UP is going to throw generations of passed down train building knowledge out the window? While this might be nice to simulate. The real world will show otherwise. Waiting to see the feedback on this one..
https://siliconprairienews.com/2021/02/new-up-developed-technology-builds-better-safer-trains/
Wisdom costs money...
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...
How do they know that this PTB system is preventing derailments or saving money in any facet of operation?
The ones that have the most problems with break in twos or threes, are mixed manifests. So you are building a 250 car train that will go 750 miles. How long does it take to check the various possiblities to get the 250 cars in the right order? What if the train is finally assembled and then the carmen bad order 3 cars that need be set out. Do you have to rerun the simulations and then reswitch the train?
Now that train is going to have blocks for two intermediate yards. To get it "right" do we forget blocking cars and just have the entire train switched at the intermediate yards? What about cars being picked up enroute? Does the train have to be "reswitched" in the computer to check the various implications of car placement?
We've discussed at work how they place a lot of stock in the simulators. Even though things in the real world don't always work as well as they do in the simulators.
Will it be as successful as the Arrowedge is?
Jeff
Considering all the car placement restrictions based on kind of car and/or commodity being handled as well as commodities that cannot be placed next to other commodities as well as long/short car placements and consecutive empties and their placement in trains as well has handling high/wide restricted loads in multi-block trains that will be involved in picking up and setting off cars along the route of the train and you end up with a genuine puzzle. Maybe PTB can solve the puzzle, maybe it will roll craps.
Never too old to have a happy childhood!
Can the buttonpushers explain the end-result of the three monster train derailments last fall? (or does PTB assume perfect train handling and external conditions - ie Wyoming weather is hearby suspended?)
My understanding is that you would feed the car list into the program and it would arrange the car order for optimum running performance. I assume that would only require a few seconds for the program to accomplish.
However, the program is only as good as the basic assumptions of train handling dynamics which the program contains. Who is to say that those assumptions are right, wrong, or sufficient to cover all circumstances and conditions that affect train dynamics?
The program could conclude that a certain consist order would cause a derailment, and thus rearrange the order to avoid the derailment. And yet it could be wrong in that no derailment would have actually occurred as the program had predicted.
The whole concept seems like paying an expert to prevent the sky from falling, so as long as it does not fall, the payment is worth it.
Face it; senior management at the railroads (or any company, for that matter) have convinced themselves technology can replace everyone on the railroad except, of course, the senior management. THOSE are the FTE's who are absolutely irreplaceable. (Insert sarcasm emoticon here.)
I should think this will cost more than it will save.
Who can override the program? If re-arranging the train to fit the program's plan will cost hundreds of dollars more than running it the way it usually runs, does that count against the program, or the poor crew stuck with making sure car #7 is where it should be according to the program. Especially when said car would normally be at the other end of the train for efficiency's sake, and it's never caused a problem there before...
Of course, if there is a breakapart or derailment, it couldn't possibly be the fault of the program...
I really don't see what all the resistance is about? Rather than seeing the program as a threat, why not see it as a support tool?
Pull aparts are going to happen regardless. But, for the guy building trains, IF one of those trains pulls apart, AND he has used the prescribed software, he just says "hey, I used the UBER TOOL that I was told to use" And it seems to me like an extra layer of insulation between his hind end and anyone inclined to chew it.
Meanwhile, anyone whose better judgement tells them the program has made a mistake, can always speak up, and have a nice "I told you so" coming after they are over ruled, and the expected problem comes up later.
Seems like "win-win" to me.
Convicted One I really don't see what all the resistance is about? Rather than seeing the program as a threat, why not see it as a support tool? Pull aparts are going to happen regardless. But, for the guy building trains, IF one of those trains pulls apart, AND he has used the prescribed software, he just says "hey, I used the UBER TOOL that I was told to use" And it seems to me like an extra layer of insulation between his hind end and anyone inclined to chew it. Meanwhile, anyone whose better judgement tells them the program has made a mistake, can always speak up, and have a nice "I told you so" coming after they are over ruled, and the expected problem comes up later. Seems like "win-win" to me.
It might be of great benefit, but it seems to enjoy the protection from critical evaluation because there is no way to know how much benefit it does provide. So the issue is that the tool applied at great cost could just be a form of patent medicine.
It is not a win-win if there is no way to know whether it is actually preventing derailments. Maybe eventually, there will be enough empirical evidence. It would also help if they explained exactly what kind of train makeup conditions this system would flag and require to be changed in order to prevent a derailment. Presumably, some of these dangerous conditions are ones not likely to be recognized by humans. They could explain that too. In the meantime, this system invites skepticism.
Without having the answers to these questions, there is no way to know if the developers have properly addressed all of the train operation variables in their programing. So the application of the system could very well cause derailments until the problem is discovered, and the system is revised.
There is also the question of what happens if the system's advice is overridden by railroad empolyees in order to address some unforseen variable en-route, as has been mentioned. What if that enroute change is made and then there is a derailment? The system makers will say it is not there fault because their advice was not followed. But the railroad officials may determine that the derailment was not caused by their makeup modification, but rather by the part of the makeup that they did not change.
It seems like an excellent concept. But is the software up to the job? I guess time will tell.
Sounds like a fancier version of CPR's program that checks the train marshalling for various territories (TrAM; Train Area Marshalling). Essentially it aims to prevent stringlining by preventing lots of tonnage on the drawbar behind long empty cars, including consideration of the placement of DPUs. Once the train is made up it checks for violations. Heavy grades and curvature make a volatile combination that can challenge even the best engineer.
Where it failed was mostly when management was reluctant to accept the delay inherent in remarshalling the train and ignored the warning. I'm sure that temptation will exist with UP's version too.
John
Lithonia OperatorIt seems like an excellent concept. But is the software up to the job? I guess time will tell.
It is one of those 'tools' that is great in concept, but may be well less than that in operation.
CSX's CADS software for train dispatching had a package to be used for the meeting and passing of trains that Dispatchers could implement on their territories at their own discretion and thus 'run their territory in automatic'. Many tried, many failed and after several were fired for codlocked territories it was rearely ever used again. Observing some of the decisions the package would make were absolutely mind boggling.
Part of the problem in 'debugging' such operational software is that those in charge of the program don't want to believe users when they state their observations; they want to see the operation locked down so they can 'back track' the logic the led to the lock down - a operation cannot afford getting to the point of lock down for the sake of debugging a program.
Euclid In the meantime, this system invites skepticism.
While your entire response is doubtlessly valid, that point in particular caught my attention. Are the people being "asked" to use this new feature simply being resistant to change, or are they feeling more like "oh great, another boss who doesn't know the drill"?
I doubt they are concerned that the computer is going to go out in the yard and take "boots on ground" jobs away from them, so where is the risk?
I used to work for a company where the one rationale that you dared not use (as a subordinate) was "well, we've always done it this way"...DESPITE the fact that the corporate officers had no inhibitions whatsover to saying "what's the matter with you? surely you must know the way things are done around here!" to subordinates triyng to innovate.
Something about the inevitability of certain things rolling down hill.
I say use it for 6 months and then make an informed decision as to it's worthiness for the intended purpose.
Operations software always end up with unintended consequence.
It will be interesting to see how this simulation places cars loaded and empty based on draft gear or eocc(end of car cushioning) end units. Placement of DPU in relation to empty draft gear and eocc. I imagine a portion of derailments from these land barges can be attributed to "incorrect" placement of loads and empties along with the type of end unit the cars are equipped with.. Then again with the block swapping involved with PSR I maybe wrong on what's incorrect placement of cars..
Unlike Vaccine tests, it's hard to do a double blind test. Or could one do a test some how?
SD60MAC9500 So it appears UP has developed software to help terminals build trains called Precision Train Builder, or PTB. It suppposedly simulates how a train will handle over any given territory. I guess UP is going to throw generations of passed down train building knowledge out the window? While this might be nice to simulate. The real world will show otherwise. Waiting to see the feedback on this one.. https://siliconprairienews.com/2021/02/new-up-developed-technology-builds-better-safer-trains/
Thanks to Chris / CopCarSS for my avatar.
Murphy Siding SD60MAC9500 So it appears UP has developed software to help terminals build trains called Precision Train Builder, or PTB. It suppposedly simulates how a train will handle over any given territory. I guess UP is going to throw generations of passed down train building knowledge out the window? While this might be nice to simulate. The real world will show otherwise. Waiting to see the feedback on this one.. https://siliconprairienews.com/2021/02/new-up-developed-technology-builds-better-safer-trains/ Maybe I'm out to lunch here, but wouldn't the software be developed using all those years of experience by various trainmen to design the algorithms that make it work. (Build ia better mouse trap without reinventing the wheel?)
Maybe I'm out to lunch here, but wouldn't the software be developed using all those years of experience by various trainmen to design the algorithms that make it work. (Build ia better mouse trap without reinventing the wheel?)
Computer algorithms can and do result in unintended consequences. Besides, computers don't accept blame and can't be disciplined.
This PTB program was not developed by an outside vendor, but rather by the U.P. itself by hiring an independent consultant who used to work as a dispatcher for them. The railroad will create the train list of cars, and then run that through the simulator. The article says this:
“PTB allows you to create a train you want to run, then run it virtually across a territory in a fraction of the time needed,” Grudle said. “It can simulate a 300-mile train run in about eight minutes.”
When it says it runs the train virtually in a fraction of the time needed, apparently that means to create and run the simulation in a fraction of the time needed. It sounds like they mean there is less “time needed” for running the program compared to the old way of not using the program.
What is that “old way” other than just some basic decisions about following the existing company rules regarding where to place empties and loads, and other key points about car location in a train?
I guess it means run the simulation in a fraction of the time needed to run the train.
It would be very interesting to creat hypothetical trains of extreme length and power, and run those over the territory to see what happens. Try trains of 1,000 cars or more for instance.
Not necessarily. All you would have to do is input your actual previous or current real world train data; schedule, crew changes, track speed, avg. speed, operating profile, length, weight, HP/ton ratio, or maximizing trailing tonnage to your consist (DPU's included). The algorithm will try to give you the best possible outcome.
Though as Jeff stated previously what happens if cars are bad ordered? Get a knuckle? Unit fails enroute? Bad weather as stated by MC..
Though I will say let's see how the software performs 24/7/365. In 2022 UP should have a better idea of the actual operating benefits.. Let the clock tick.
Euclid It would be very interesting to creat hypothetical trains of extreme length and power, and run those over the territory to see what happens. Try trains of 1,000 cars or more for instance.
I would say that's the reason UP had this software developed. To see what the hypotheical's are to run even bigger trains, and what any pratical limits would be.. If the software shows you can successfully run a 20,000' stack train. I wouldn't put it past UP to trial and even put into regular operation a train of such proportion. Will it be a mess? Possibly... Remember that 3 mile long stack train UP ran back in 2010? That was just the beginning.
https://www.latimes.com/archives/la-xpm-2010-jan-13-la-me-monster-train13-2010jan13-story.html
As in any simulation, the proof in the pudding is whether the simulation has been validated. Having the simulation developed by a former dispatcher helps, though I would wonder if it takes all of the relevant train dynamics into consideration, e.g. slack run-in.
FWIW, simulating slack run-in has been something I've wondered about since reading "9800 tons" article in a late 1970's Trains. Article was written be a former GM&O engineer about handling a train at least a third heavier than what the dispatch told him. Considering all of the time scales involved in tracking every single car and accounting for the actions of free slack and draft gear, I would be astonished that it could be simulated in anything close to real time.
PTB is just something they want to validate their belief that they can keep on building and operating longer and longer trains. That a certain percentage of ever longer trains is of no consequence, as long as the acceptable failure rate is not exceeded.
jeffhergert PTB is just something they want to validate their belief that they can keep on building and operating longer and longer trains. That a certain percentage of ever longer trains is of no consequence, as long as the acceptable failure rate is not exceeded. Jeff
Jeff, I don't understand your second sentence.
Lithonia Operator jeffhergert PTB is just something they want to validate their belief that they can keep on building and operating longer and longer trains. That a certain percentage of ever longer trains is of no consequence, as long as the acceptable failure rate is not exceeded. Jeff Jeff, I don't understand your second sentence.
A failure in 1 in 100 trains may be acceptable - failure in 20 in 100 trains may not.
There is some level of failure that is acceptable in train operation (as hard as you may try you will never get to zero failures). Operations in these kinds of circumstance is really a exercise in probability.
[quote user="Euclid"]It would be very interesting to create hypothetical trains of extreme length and power, and run those over the territory to see what happens. Try trains of 1,000 cars or more for instance.[/quote]
Just to clarify, I mean to create the hypothetical (virtual) trains of extreme length and power, and then run those hypothetical trains as being hypothetical models, over the territory as being hypothetical. It would not actually be a real train, so there would be no risk. It would be a cheap experiment that might yield mind boggling results which might be used in various ways.
Even if the DPU transmission cannot be extended as far as desired, just model the train as though it has unlimited DPU transmission length. Just set that issue aside and see what the makeup program thinks of an super-long train.
Then run a simulated train of say 50,000 cars, and see if the program can arrange the train makeup so that it works without any problems. That would be quite the news story if the system says it works fine.
Try it with mixed consits and with unit trains. What do you think the system would say about a 50,000 car train? I suppose it might say something about grade crossings.
EuclidTry it with mixed consits and with unit trains. What do you think the system would say about a 50,000 car train? I suppose it might say something about grade crossings.
My bet is that the program does NOT have any grade crossings in it. Only the Rairoad. Public Relationsis a different department.
Our community is FREE to join. To participate you must either login or register for an account.