Timetable pools

Registered by r.roeterdink

This blueprint proposes to introduce the concept of pools to the timetable mode.

Background:

The timetable mode offers the ability to keep trains ‘alive’ until they are needed again later. These trains, which may be light engines, multiple units or indeed full trainsets, are stored in sidings until they are required again for the next service. In busy areas, like yards, terminal stations and such, the number of units which are stored this way can be quite large.

At present, it is up to the builder of the timetable to ensure such units are send to and retreived from the storage in the correct sequence, which means a full diagram has to be worked out of when train are due to enter the storage area and when they are required again. This can be quite complicated.

Description:

The pool concept will take care of the storage requirements. When a train is send to a pool, the pool logic will work out where to store this train. On request of a train the pool will work out which train is available, and will release this train from the pool.

All trains in a pool are supposed to be the same, that is they are all interchangeable. They need not be the same trains as such, but be equivelant. It is not possible to set additional requirements when requesting a train from a pool.

So, for instance, if storage is required for both diesel and electric engines, this will require two pools, each with their own storage area.

Warnings will be issued in the log-window in case of pool ‘overflow’ (not enough storage room when an engine is send to a pool), or ‘underflow’ (no engine available on a request for release).

Defintion:

A pool is identified by a unique name.

Each pool contains one or more storage areas, defined as a path. At present, only dead-end storage areas are supported (ie there is only one entry/exit point per storage path).

Each storage area is linked to one or more access paths, which define the path from an exit/entry point to or from the storage areas. All storeage paths must have an access path to all defined exit/entry points. There can be multiple exit/entry points, but each storage area needs to have access to all these defined points.

Path of trains to or from the storage area must only be defined to or from an entry/exit point.
As pools are part of a timetable definition, the definition file needs to be stored in the same directory as the timetable files (subdirectory OpenRails in the route’s Activity directory), and as timetable files it needs to have .csv format, with file extention .pool_or.

There can be multiple pool definition files, and each file can contain multiple pool definitions.

Train commands:

A train can be send to a pool by the command $pool=<name>, set in the #dispose line.

A train can be retreived from a pool by the command $pool=<name>, set in the #start line, preceded by the time at which the train is required.

A train can be defined as starting in a pool by the command $create /pool=<name>, set in the #start line, without time. The train will be created at the start of the timetable.

Testing and evaluation options:

When there is a pool ‘underflow’, no engine is available and therefor no engine is send out on the request for an engine release. A user option is envisaged, 'force create train on underflow', which will forcibly create an engine when this situation occurs. This can be used during testing of a timetable, when it is not yet quite clear how many engines are required.

Further options may be defined for pool evaluation. How this will be done exactly is still being considered. One possibility is to set an option to print all pool details to a specific file, these details will contain timings on when engines enter and leave the pool, total no. of engines in the pool after that action, total available space, and underflow and overflow situations.

Another possibility is to add this information as a new page to the F5 hud info.

Discussion: http://www.elvastower.com/forums/index.php?/topic/29986-proposal-to-introduce-pool-concept-in-timetable-mode/
Roadmap: https://trello.com/c/t7W125ZL/297-timetable-pools

Blueprint information

Status:
Complete
Approver:
James Ross
Priority:
Medium
Drafter:
r.roeterdink
Direction:
Approved
Assignee:
r.roeterdink
Definition:
Approved
Series goal:
None
Implementation:
Implemented
Milestone target:
milestone icon 1.3
Started by
r.roeterdink
Completed by
James Ross

Related branches

Sprints

Whiteboard

Implemented in X3863.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.