1.4.1. Setting Routes over Boundaries
Suppose that one wished to route a train from S7 to
S5. On receiving the panel request for this route East first
evaluates the availability conditions in its portion of the network:
if these are not met the request simply fails, otherwise East must
wait until it is certain the route is also available in the other
Interlocking before locking it. To achieve this East issues a
remote route request to West over the internal data link.
On receiving such an input West should handle the request just as it
would handle route requests coming directly from the control
panel---this simplifies the design of the control interpreter, and
data preparation. Thus an incoming IDL request will be translated into
a panel request and queued in the usual manner. When a remote route
request is subsequently processed the difference is that West must
communicate to East if, or when, the route is locked: West sends
its acknowledgement via a reply telegram to East over the IDL.
In East the acknowledgement is also treated as a remote route
request: on this occasion East proceeds to lock the route it had
originally requested. The two Interlockings need to use a dedicated
pair of IDL telegrams to communicate request codes and their
acknowledgements. Normally, many routes over numerous lines link the
two signalling areas, but a single pair of (eight bit) telegrams
should suffice to carry all the necessary request codes and their
acknowledgements. To summarise:
Once the route has been locked in East the aspect of the entrance
signal can be changed if the prevailing conditions allow this. For
example, only if the tracks down to the exit signal are clear, and if
opposing signals are on, can East clear the signal---to green or
yellow, depending on the aspect displayed by the exit signal. Thus,
in addition to the telegrams used to convey request codes, another IDL
telegram is needed to convey the status of tracks and signals in the
fringe area. Such data are needed continuously.
East receives a panel route request for a cross-boundary
route. If the route is available in East, issue a remote route
request to West.
West receives an IDL input conveying a remote route
request. If the route is available, lock the route and reply to
East with an acknowledge telegram.
East receives a reply telegram to the earlier remote route
request: it can then lock the route and control the entrance signal
Matthew Morley, Edinburgh. Date: 29 November, 1998