Track Movement Sequencing Logic

From Planimate Knowledge Base
Revision as of 17:07, 15 November 2008 by Tony.Griffith (talk | contribs)
Jump to navigation Jump to search

Track Movement Sequencing Logic

A dynamic network model strives for realism. It must strike a balance between the provision of enough traffic management rules to reduce the probability of deadlocks, and the provision of so many rules that the traffic-carrying capability of the system becomes unrealistically low.

The Planimate® Platform contains logic for controlling train item movement around a track network. The underlying philosophy is to aim for simplicity and to provide modellers with immediate traffic management over a network without them having to first design any movement rules of their own.

By design, the logic does not optimise localised train movement scheduling, nor does it perform overall system-wide trade-offs. Train Item movements are resolved on a first come first served basis and the Platform manages what it is presented with locally.

In the case of simultaneous competition for a section, the train item with the highest ‘priority’ wins out, depending upon the circumstance. In conditions of “moderate congestion”, the movement logic may "relax" priority-based assignments in the interests of moving trains through the system to ease the congestion and release capacity.

However if you move trains into a track network, assigning trains to sections, roads and loops using simple rules to avoid ‘collisions’, you end up with a deadlock in short order. The issue of deadlock limits how simple you can make the rule set with which train item movements over a network are managed.

The rules that guide train item movement decisions have to respond to the wider “network context” within which each train item’s movement is contemplated. Each decision requires knowledge of where other relevant train items are in the network and where they are heading. Some movements will increase the chance of deadlock developing more than others.

Making movement decisions by taking full account of the position and routing for every train on even a simple network consumes huge memory and processing resources. The Planimate® Platform avoids this overhead by adopting a general rule set designed guide decision-making about moving each train item individually, given the “network context” within which it finds itself.

In order to reduce the chance of a deadlock occurring, the Planimate® Platform uses rules developed to favor train item movements that tend not to constrain the movements of other train items. Of the many possible ‘next movements’ in a network, given the specifics of network occupancy at that time, some will not comply with these general rules regarding train movements toward, and be disallowed.

During a simulation run, the rules in this logic pursue a balance between these basic goals:


  1. To facilitate reasonable sequencing of train item movements over the network,
    And at the same time…
  2. To avoid train item movements that increase the chance of a “deadlock” occurring.

Deadlock

Deadlock occurs in dynamic rail network models when two or more train items become blocked and cannot proceed past each other at some location in the rail network. Other train items then start to queue behind these blocked trains until all train items in the system become blocked. Cycles and routes do not conclude and the model run cannot be completed.

When your model experiences a deadlock it means that the rules for managing train item movements are insufficient to prevent those movements that bring about that particular deadlock situation. The deficiency could reside in the Planimate® Platform itself, or in the modeller’s own additions, extensions or modifications of the rules used by the Platform. In either case, the specific deadlock conditions can be analysed and the modeller can develop rules to prevent the situation occurring.

As you develop your rail model, growth of network detail, dynamic capacity assignment, more sophisticated ‘look-ahead logic’ and higher traffic levels, produce growing numbers of network states that can result in traffic deadlocks. The enormous number of possible combinations of traffic movement in a network means deadlock conditions are extremely difficult to predict. They can occur at any level of traffic density. Unfortunately this means that deadlocks need to be addressed as they appear.

Heavy or extreme congestion can produce deadlocks.

This is taken as a sign that this part of the track network has been forced beyond its actual capacity, and the traffic needs to be reduced or smoothed out, or the area in question requires some investment to raise its capacity.

It is also possible for a deadlock to occur in relatively light traffic circumstances, if an unfortunate arrangement of movements occurs.

Traffic deadlocks are an inevitable part of using dynamic network models with conflict resolution rules. The reality is that deadlock issues will accompany your rail model development and its use.

Whilst no guarantee can be offered that deadlocks will never occur, it is realistic to expect that the frequency of deadlocks will be reduced as more attention is paid to refining traffic management rules implemented into the rail models themselves, as well as into the Planimate® Platform.

Reducing the Risk of Deadlock

Much effort over the years has been expended (by both modellers and software engineering in the Planimate® Platform itself) to identify causes of deadlocks and to develop solutions that prevent them, or lower the risk of traffic deadlock situations occurring.

Deadlocks reported to InterDynamics are examined to determine whether there is evidence of a general case for which rules may be developed or refined and applied into the Planimate® Platform’s rule set. A general case rule addition or refinement will be tested, after which an updated platform executable is made available. This results in a lowered risk of reappearance of that deadlock situation, or others similar to it.

It is important to note that for rail models with a significant history, a rule refinement to address reported deadlocks may alter the results of prior scenarios.

Upon receipt of new executables with changed movement rules it is important to identify and report differences ahead of any further use of your rail model.