There are two aspects to Train Control.
The first aspect involves how one goes about getting the train in the right place at the right time without having it get tangled with any other trains, all of which have to also get in the right place at the right time. The second aspect is how one goes about getting and keeping the controller (in most current rail transport modes in the United States, this is the "engineer" or "operator") in control of the train while complying with all the requirements of the first aspect.
For literary convenience, we will refer to the current state of railroading as the Current Mode or CM. Next Generation Rail is NGR.
In CM, the two aspects of train control are not fully integrated, and the stumbling block to full integration is human. In CM, all of the data that is produced and constitutes the first aspect must pass through the human engineer to get to the second aspect. For example, a train order, schedule and/or signal must be obeyed. The engineer, assimilating all the data, must run the train to the best of his ability by manipulating the throttle, automatic brake, dynamic brake and/or engine brake in such a way as to accomplish the task of the first aspect - keep the train in the right place at the right time.
Though there are a few technologies in CM that bypass or at least ignore the human interface - automatic train stop, positive train control, automatic train separation, etc. - none seek to put the needs of the first aspect directly to work on the second aspect.
This part will anger the operating unions: NGR should not need an engineer as a train operator. The only need for an on-board engineer should be to monitor on-board systems and keep the machinery running. The on-board engineer in NGR should be approximately what the fireman was to the steam locomotive, only with a broader knowledge of systems and computers to match NGR's complex locomotives.
Before we talk about the out-there systems that will keep the trains in the right places at the right times, we would like to say a bit about the on-board control systems for NGR.
With today's state of computer science, interoperability of computer components, information technology, communications and micro-electronic control, and with the anticipated future state of these disciplines . . . THERE IS ABSOLUTELY NO REASON WHY OPERATING A REAL TRAIN SHOULD BE ANY MORE DIFFICULT THAN THE DCC CONTROL OF A RUNNING MODEL TRAIN. It is simply the entrenchment of the current state of control systems that keeps them en vogue, and the reluctance of manufacturers to take a cutting edge and attempt to slice into sales of CM technology. In a nutshell, NGR technology for the on-board portion of train control already exists.
He's NUTS! No such thing exists!
Yes it does! It exists in many current components and hardware that, if properly brought together can make such a system without any great leaps in hardware or software technology. It also exists on so many drawing boards and in the minds of so many designers. Any one of you who has comprehended what we have said so far and gotten to this argument in this post knows this. Also, think of the current state of remote control locomotives. Though the system is still too complex and adapts to CM instead of offering simplified systems and data, this is a very viable first step.
So the CM aspect of train control that now includes all on-board control systems and the operating engineer will, in NGR, be nothing more than the process of adjusting a DCC control (For the unitiated, this is computerized, digitized model railroading at its current state of the art.) to move the train to where it should be when it should be. But for NGR to work, we've got to get the first aspect of train control, keeping trains where they should be, to interface with the second aspect.
More about NGR and the first aspect of train control in a future blog.
© 2006 - C. A. Turek - mistertrains@gmail.com
1 comment:
There's two parts to next generation train control - the running of the trains and the intigration into signal systems and traffic control.
The critical questions aren't can we do it. The question is what benifit (productivity or safety) would it gain us to spend all that money.
Being able to reduce crews from two people to one is an obvious benfit. But this wouldn't require replacing the engineer's running skills, only a better way of ensuring compliance signals and that the train would stop if they were incapacitated.
We can create kind of an autopilot, but why? It wouldn't be necessary in order to gain the benifit of reduced crew sizes.
One benifit might be in order to acheive fuel efficiencies from better train handling. But I don't see the benifits from that outweighing the costs.
A completely different productivity benifit is in line capacity - being able to create rolling blocks and planning meets far in advance.
Post a Comment