Controlled Signal or Block Signal? In another discussion of CTC it was stated:
>The authority is granted by Controlled Signals.This is still a point of some disagreement. GCOR defines CTC as:
A BLOCK SYSTEM THAT USES BLOCK SIGNAL INDICATIONS TO AUTHORIZE MOVEMENTS.Nowhere does it say Absolute Signal or Controlled Signal. It says Block Signal. Some people take this to mean that any signal authorizes movement.
Thus if you reverse direction within an intermediate block you are making a Reverse Movement within that block to the first signal behind you. On BNSF you do not need DS authority to do that (Rule 6.4.1). If the first signal behind you is green it then authorizes your movement in that direction, so when you pass it you are no longer making a Reverse Movement (movement opposite the direction authorized). Thus since you are not making a Reverse Movement you do not need to contact the dispatcher to get permission for a Reverse Movement. Even if that signal is an Intermediate! It is a block signal and in CTC block signals authorize use.
That signal does not even have to be green. If it is an intermediate signal it still authorizes movement even if it is red or any aspect between green and red. Stop & Proceed or Restricted signals authorize movement.
As far as I can see there is no danger for that train or other trains in doing this if the signal displays a green aspect. If the signal is green there can be no movement opposing you. Changing direction might cause a traffic jam down the line but there is no danger between trains.
There can, however, be MOW following you and MOW usually does not activate block signals. I presume this is the reason BNSF changed the rules requiring MOW to notify trains when they are setting on behind them. After having been so notified trains can not back up without contacting the MOW first.
That said, I am not one of those who operate this way. If I am going east and change direction and want to move outside my current block I always call the DS and get permission (authority?) to proceed westbound. Regardless of what indication an intermediate block signal displays behind me. But I am not convinced that this is required by the rules. It is just my own personal extra layer of protection and it prevents potential nose to nose traffic jams down the line.
It is best to always keep the DS informed of any movement other than straight forward. However if I advised the DS two hours ago that we were going to Kiewit, pick up two cars, and return to Sheridan then I see no requirement by the rules to get permission (authority?) to pass the green intermediates on my return trip. The proceed indications of those block signals are the authority for my movement in CTC.
I said it is safe if the intermediate signal is green. However it is not safe if that signal is red. If the signal "behind" you is red then there could be a train following you. If you reverse to that signal then accept that Stop & Proceed (or Restricted in the case of a Grade Marker) as an authorizing block in CTC there could be a collision. That is because the following train may have just passed the yellow signal leading up to the red for the block you are occupying. If you then move past that signal at Restricted Speed you will be in "his" block. Depending upon the timing of these actions that train may be traveling with some speed in "his" yellow block when he encounters your train. But the point is that the text of the pertinent GCOR rules does not prevent you from doing that!
At the very least, on all CTC systems I am familiar with, moving past an intermediate signal behind you will cause all of the signals governing a following movement in your original direction to tumbledown to red all the way back to the previous absolute signal. That can result in a following train encountering an unexpected red signal.
I have been told that BNSF _interprets_ these rules to mean that you must get dispatcher permission to pass that first signal that was originally to your rear. I agree that is the only safe interpretation. But it is an interpretation made up from the wild blue. The GCOR rules do NOT support that interpretation. But it is their railroad. I have argued this point until I am blue in the face. This is a flaw in the GCOR.
Furthermore, suppose that a train reverses direction within the block immediately beyond a CP (Control Point). It can make a reverse movement within the same block just as before. But this time the first signal it encounters behind it is the controlled signal at the CP. If that signal is anything but STOP then the train is going to accept that aspect and proceed beyond the CP WITHOUT contacting the dispatcher. It is done hundreds of times every day across the system. Now I ask, what is the difference rule-wise between this scenario and the scenario above where the first signal behind you was an intermediate? I say that according to the written rules there is no difference.
This whole mess can easily be cleared up by changing the definition of CTC to state:
CENTRALIZED TRAFFIC CONTROL (CTC):
A BLOCK SYSTEM WHERE TRAIN MOVEMENTS ARE AUTHORIZED BY CONTROLLED SIGNALS.With that in place then when a train reverses and reaches that first intermediate signal it must still get dispatcher permission to proceed since that is not a controlled signal. And in my last scenario above where the train reversed just east of the CP, the train would not need dispatcher permission at the controlled signal after reversing.
It gets murkier. There is another thing to consider. Rule 10.1 states that
A TRAIN MUST NOT ENTER OR OCCUPY ANY TRACK WHERE CTC IS IN EFFECT UNLESS: A CONTROLLED SIGNAL DISPLAYS A PROCEED INDICATION... or verbal authority is granted.Clearly this requires a CONTROLLED signal. But if I am already on a CTC main and merely change direction does this rule govern? Am I ENTERing or OCCUPYing a CTC track when I move beyond my present intermediate block? If you interpret enter and occupy in this manner then you can NEVER go by an intermediate signal in either direction regardless of its indication because to ENTER or OCCUPY requires a proceed on a CONTROLLED signal. Obviously you cannot interpret the words enter and occupy to mean moving from one intermediate block to another. That interpretation will not work.
Further more, if you read rule 10.1 literally this rule says you cannot OCCUPY without a control signal showing proceed. Hmmm? If I am sitting on a CTC track, say on the main between switches at a siding, and I have a red signal in front of me and a red signal behind me am I in violation of Rule 10.1? I am OCCUPYing a CTC track and have no proceed indication. I ENTERed that track with a controlled signal displaying proceed but I am OCCUPYing it without one. Clearly they mean the words enter and occupy to be one and the same thing, enter. So why state both words?
Conclusion We have determined that we cannot interpret moving from one intermediate block to another as ENTERing or OCCUPYing a CTC track under Rule 10.1. It won't work to do so. Therefore rule 10.1 does not apply when you are already on a CTC track at an intermediate point. Since the definition of CTC states that BLOCK signals authorize movements, those intermediate block signals must authorize your movement. If you have a green or any other color you can go.
The problem of interpretation of the word ENTER has come up in several other discussions of rules. Every time it is interpreted to mean something other than the "INITIAL occupying of the authority limits" it causes problems. If you are already in the room you cannot "enter" the room. If you are already in your authority limits you cannot "enter" those limits. I don't believe the authors of the GCOR meant for the word enter to be interpreted in any other way. The rules work if you stick to that one meaning of the word. If you use a broader definition of the word enter then it often presents dualities like this one. In one situation you have to interpret the words one way and in another situation you have to interpret those same words in a different manner.
In my opinion the words "or occupy" should be removed from rule 10.1
Return to Tales index | My Home Page | E-Mail me |
Created 08-01-2002
Updated 10-12-2006