After reading about dispatching in the latest issue of Trains Magazine, I’m curious why a computer program can’t do most of what a dispatcher does.
Couldn’t someone develop a program, where you input all the pertinent data about the trains involved, and at the very least, have the computer make suggestions about what to do with the trains? Someone was explaining a program that would suggest the best next move during a chess game, based on where all the pieces now sat. Wouldn’t that be similar logic?
A dispatcher (DS) is better described as a coordinator. If only it was as easy as running trains. A DS has x miles of track. A DS has y number of road trains. There’s a natural priority for trains, but that can be changed depending on needs and times of crews. There’s track patrols, heat patrols, cold patrols, storm patrols, welders, MOW (small and large projects), MOW equipment that needs to tram to and from sidings to work sites, maintainers doing monthly/quarterly/yearly switch & signal tests. Locals that have to work different industries each day that need to occupy the mainline for different periods of time. Work trains that have to do things like pick up/ lay rail or ties. Trains that call in with problems, everywhere from signal issues to thieves to other oddball stuff that has to be addressed and sent to the correct departments.
Have to know where to hold a train so it will fit between road crossings, or away from other sensitive areas. Have to take into account tonnage and power when running or holding a train iwith concern to grades or hills. A DS may have yards that just can’t handle any train you throw at them. So you have to strategically place or hold trains until the yard is ready for them. Sometimes doing that miles and miles away, so you don’t clog up the rest of the territory.
Then there’s the need to provide protection for MOW, or signals when they fail, or when speed restrictions are put in place, until they are added to bulletins.
The dispatchers at Spring Texas, in the Joint BNSF/UP dispatching center use computer programs designed on just such a concept.
But, as was pointed out to us when the center went in, computers can’t “think their way out of a problem”…all a computer can do is follow the program it is running.
In order for the computer program to be able to handle every single scenario there could possibly be, the program would be quite complex, and the computers main frame would need to be close to a Cray type system.
Dispatchers are the oversight program for the system.
They can easily override the system if the movement they “see” will save time and money.
If you compare what a dispatcher was and did before the NORAC rules then you would’t be asking that question as a lot of dispatching is done by computer. But the initial make up of the train or trains has to be done by man somewhere along the line…and with that, man has to be able to ride, oversee, and override any and all computer programs. If something happened enroute, often it is a person who gets the alert and has to change the computer settings. A derailment or hitting a trespasser or whatever the circumstance gets reported to the dispatcher who in turn manipulates the computer program to keep things moving and safe…most likely, too, the report will come from a real person rather than a computer and that person probably doesn’t have, or shouldn’t have, access to the dispatching program…
As pointed out by others, if the world was perfect and things didn’t go wrong, they could be replaced. As we all know, many things on the railroad do no go to plan, and at this point a computer can not replace the human thought process for that.
A Vision For The Future: Intelligent Railroad Systems
The following quoted from the link details three concepts related to yardmaster and dispatcher roles. The linked report details a total of 26 visionary concepts for things like locomotive health monitoring, crew scheduling, crew alertness monitoring systems, etc.:
Tactical traffic planners (TTPs) produce plans showing when trains should arrive at each point on a dispatcher’s territory, where trains should meet and pass, and which trains should take sidings. As the plans are executed, a TTP takes the very detailed train movement information provided by the PTC system and compares it with desired train performance. If there are significant deviations from plan, the TTP will re-plan, adjusting meet and pass locations to recover undesired lateness. TTPs make use of sophisticated non-linear optimization techniques to devise an optimal dispatching plan. Once a TTP prepares a plan, the dispatcher need only accept it. Then the computer-assisted dispatching system of PTC produces all authorities needed to execute the plan and sends them over the digital data link communications network to trains and maintenance-of-way vehicles. Some prototype TTPs have been developed and tested.
Strategic traffic planners (STPs) - TTPs cannot function without knowing the schedule for each train. STPs measure train movements against a set of externally defined schedules that include information on scheduled block swaps and connections, both internal and with other rail
Maybe I overstepped my case by saying replace the Dispatcher with a computer. (I was probably just trying not to mention hobos [:-,]) More ralistically, could a computer dispatch type program be used to, let’s say, compliment the work of the dispatcher? I fully understand, that a lot of dispatching would fall into the “more of an art that a science” type thing.
In effect the Philadelphia area Lindenwold line (PATCO) and the NY MTA’s Skytrain from Jamaica to JFK field are computer dispatched and operated. But they are highly scheduled, short, and closed systems unlike a freight railroad.
I haven’t been in the CSX dispatch office at Selkirk, but I do know from listening to them over the years that they are using computers in their jobs. My impression is that the computer serves as sort of an interlocking - sections of track are assigned, and once assigned, cannot be assigned to another train or other user.
On the other hand, the dispatch office we use is totally manual. Of course, if I get a two digit Form D, I’m usually amazed. The numbers start at 1 each day.
Then there is the phenomenon of one train following another in dark territory. As the lead train gives up territory, new authority is issued to the following train. The cost of automation down to the end user (RR crew) would be pretty high, so the human interface (dispatcher) handles it, getting track back from one crew and giving it to another.
I’ve been in the IT business for over 32 years and we are not that far off for when the computing power will handle these variation, say less than 10 years. Given the budget, a dispatch application can be programmed now and would not put it pass us that the requirements are being written now. With GPS down to the cell-phone level, everyone’s location is visible; which is the key variable in designing such a dispatching program. Heck, the trucking industry has been using dispatch programs for years.
To give an example, I had written such a program that took route, location, fuel (coal), water (this was a steam RR simulation), grades, crew service time, delivery schedule and failure probability into account all on a FoxPro spreadsheet ( I am dating myself.) It was all part of an operational probability MBA level class final project and got me an A+. Given the high level of Object Oriented program languages today, it just take a consideration to invest in developing this a RR oriented dispatch system over the cost of human capital to manually manage the RR network.
When it comes time to maximize the RR network capacity, then we’ll see the investment in automated dispatch software. It’ll be the time where the DS can’t think through that many variables to move all the trains ahead. “HAL, open the pod-bay doors.”
Complete agreement with HENRY6 of 7:08 PM 22 Oct, and admiration for the PC-correct distinguishing among man (I hope meaning hu-man) person, real person.
In his msg “whatever circumstance get reported to the dispatcher”…a rock that sprayed window-glass rocklet chips all over me—spread-out from the GP9’s chair to the cab heater box foot-rest below the front window.
I said I had a problem that I was covered with glass chips and within 20 miles a change of clothes to a jump-suit supplied to the mech, dept. would work. That I wore the cover-all jump-suit home after completing the last three- quarter"s of the day’s work say’s something about the ability of programming a “dispatcher” computer.
Fifty bi- and tri-levels of auto’s and trucks moved 'cause of an improvisation by a dispr.
My scanner is on in my office most of the day for background noise…what did I hear dispatchers handle yesterday:
Issue track warrents in dark territory.
Handle the complexities of an interlocking crossing going dark all day due to signal work and having to coordinate movements, including movements of 17000 coal trains at the base of a 1% grade.
Plan for possible stalling on the above grade when one locomotive went dead (train topped out at 8mph, but the plan was in place).
Discuss rules with a crew regarding running a train based on brake issues (the rules won).
Coordinate MOW work on a busy mainline and then “run 7 westbounds” in pretty effecient manner along with a couple of a couple of heavy eastbounds (up a 10 mile grade).
Weave locals, heavy coal trains, Amtraks and hot 60mph UPS and intermodal trains thru some of the busiest double track east of the Mississippi.
Anticipate terminal delays in Chicago and plan accordingly.
Maintain a cool and professional demeanor at all times.
(edit) Here are a couple others…issue EC-1’s covering speed restrictions and malfunctioning road crossings and cancel speed restrictions/road crossing restrictions as they are cleared…these take considerable time.
The Trains article was outstanding, finally read it yesterday, but I dont think non railroaders have a clue as to the complexities involved in operating and managing a complex line. I listen almost daily and find it a fascinating and complex task…and I only “hear” a fraction of what is actually happening.
Computer Aided Dispatching System (CADS) is a tool designed to assist in doing the job of regulating rail traffic and all the maintenance functions required to keep line segments fluid. No matter how much logic is programmed into the tool - is is still a TOOL. Just like any tool, some individuals can operate it better than others.
Good Dispatchers get paid on their vision - not what is happening now, but what will be happening four to eight hours after the end of their tour of duty. To be effective working any particular trick, you must understand the railroad requirements of the trick that follows you. Computers can only work on the data they are presented and presenting them data too far in advance of NOW end ups with some curious decisions being made by the logic.
Just like a track man uses a spike mall as a tool, and the signal maintainer uses a ohm meter as a tool, so does the dispatcher use CADS as a tool.
Let an outsider suggest a good reason that the dispatcher is a human:
Responsibility. The computer can calculate and decide and certainly
advises the human. But the human has judgement not just decision
techniques. So the human is responsible.
Replacing dispatchers with computers ?!? [:-,] That’ll probably happen right after Air Traffic Controllers and most major roadways - not just the Interstates - are computerized, too.
More seriously, it will probably depend on the presence and extent of such parameters/ characteristics as:
Simplicity (for feasibility and lower implementation cost);
Repetitiveness, patterns, and lack of variation/ deviations from the norm (for the same). Once a good solution to a common situation or pattern is figured out and standardized, it may be a lot easier to force the traffic to fit into that solution, rather than custom-tailoring and reinventing the wheel each time that situation reoccurs;
High volume of traffic (for need, and to maximize the cost savings, etc.); and,