[Go Up], [Go Back].

1.3.3. Examples of Geographic Data

A more thorough account of the Geographic Data Language is given in Chapter 2, but it is easy to introduce the main concepts occupying later chapters through a few examples. Figure 1.3 reproduces the scheme plan for the layout in Figure 1.1 with further annotations to show routes and sub-routes.
[plan]
Figure 1.3: The scheme plan signalling layout in Figure 1.1 with route and sub-route annotations. Routes are identified paths between main signals, and each track circuit is associated with a collection of sub-routes so that a sub-route is defined for each path through a track circuit that lies on a route. A sub-route may be a component of more than one route (as T7ba, for instance).
Route R28 proceeds from S2 to S8 through the points P2 and P3 reverse and normal respectively. In this scheme plan, there are four sub-routes associated with T4: westward T4ab and T4ac, and eastward T4ba and T4ca. Thus R48 (say) can be identified with the sub-routes T4ba, T6ca, and T7ba in that order, by the points P2 and P3 which are required normal (and any overlap beyond the exit signal S8, but shall not consider overlaps at present). These entities are control variables upon which the Geographic Data and control interpreter operate.

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 cnf is 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, T7ab 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 T7ab f 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.


[Go Up], [Go Back].
Matthew Morley, Edinburgh. Date: 29 November, 1998