The Geographic Data are conceptually organised into a number of files each of which holds data that serves a specific purpose. Some of these files are accessed at random (as, for example, when a panel request is processed), whilst others are processed in rotation, once a major cycle. Thus, data in the input data file are responsible for copying the incoming status information to memory, and the output data file contains data that determine the command to be issued to each TFM as the system evolves. These data are accessed periodically, and there is one block of code to execute corresponding to each telegram. For example, the data listed for the command telegram for signal S2 will specify the conditions under which the signal can be switched off (i.e., from red to a less restrictive aspect). These will typically include checks that S4, S7 and S9 are on, that the points on the route are detected (in some position), and that the track circuits to the next signal are clear. These data are designed to ensure that signals remain at red unless an onward route is locked (e.g., by testing the appropriate route variables)---though this is a property that should be checked.
The conditions under which a route may be locked, and the locking conditions for the route (i.e., the conditions that must not change while the route is set), are specified by route request data. For the running example:
*Q28 if P2 crf, P3 cnf, T4ac f, T7ab f then R28 s, P2 cr, P3 cn, T4ca l, T6ca l, T7ba l \ .This guarded command is a statement in the Geographic Data Language that is executed in response to a route request issued at the signal control panel. Execution begins at the label
*Q28(which is treated as a pointer into the static data table), and continues without interruption up to the `
.' which terminates the command. Several variables are tested here: points P2 are tested to see if they are controlled reverse or ``free to move'' reverse (P2
crf); similarly, P3
cnfis a test to see if these points are normal or ``free to move'' normal (a more detailed discussion of the points test is deferred until Chapter 2). In addition, several conflicting sub-routes are tested (T4ac
f) to check that they are free. If all these conditions are satisfied the route is locked by updating the variables as specified in the conclusion of the rule: the route variable is set, the points are controlled reverse and controlled normal, and the sub-routes are locked. (The terminology of railway signalling is used here, but it is mildly confusing to speak of the route being `locked' by this action, rather than `set', although the control variable for the route is `set'. Note that the signalling actions in setting a route are firstly that it is `locked', then it is `proved'; the route is finally `set' when the entrance signal displays a proceed aspect, usually green.)
Another class of Geographic Data specifies conditions that govern route release. It is (usually) necessary to lock routes in a single action, but they can be released gradually as the train proceeds, `freeing' the network to the rear. Such bookkeeping is carried out by commands listed in the sub-route release data file which are executed sequentially over the course of a major cycle. Continuing with the example in Figure 1.3, these data may specify:
T4ca f if R28 xs, T4 c \ . T6ca f if T4ba f, T4ca f, T6 c \ . T7ba f if T6ca f, T6ba f, T7 c \ .These rules introduce the following signalling principle: the first sub-route on a route can be released (freed) as soon as the route has been unset as long as the track circuit is clear; subsequent sub-routes are released in the sequence they are traversed. The sub-route release data must specify the sequence correctly. The order in which the rules are specified in the file, and hence the order in which they are executed, is immaterial---more precisely, safety properties of the interlocking must not depend on the order.
To illustrate the importance of this, the test
should be sufficient to guarantee that neither of the conflicting
routes that terminate at S5 is locked in when R28 is
locked; indeed, if a train on R95 (say) has passed the
entrance signal but not yet cleared T9, this test in the
availability conditions for R28, and similar tests in the
rule for R95, will ensure that these two routes do not
interfere however far the train has progressed from S9. The
command to unset R28 is executed from the output
data file (usually when the data for signal module S2 are
processed). A route is unset in response to a cancellation request
from the signal control panel (or automatically as the train enters
the route), but the conditions under which the entrance signal can be
returned to red will depend on whether an approaching train is within
sighting distance of the signal.
The problem we have to face is to determine whether the locking conditions in rules such as the above are adequate to ensure that trains do not run an undue risk of a collision or derailment. This is clearly not a trivial matter. In order to approach this subject the semantics of the Geographic Data Language are discussed further in Chapter 2, and properties of the data are examined in succeeding chapters. The next section introduces the remote route request protocol which is investigated in Chapter 5, and explains the mechanisms that enable several Interlockings at the control centre to communicate to achieve their collective management of larger railway networks.