Editing User Cases

Example user cases are listed below.

= Understanding Platform Occupation =

The platform docker will only render trains that have been called and that are within the acumen forecast. 

Passenger trains are typically automatically called 1-2hrs out. This is why when you scroll ahead in time the trains appear less frequent. Additionally, you may see a terminating service with a blue association dot but no line associating it with its outbound service. This is probably because the outbound service has not yet been called.

To see the intent of the plan which includes trains that have not yet been called, turn on the <b>Planning Layer</b> from the Docker Viewing Preferences. <i> For more information see [[Platform Docker Display#Planning Layer]] </i>.

To see the train plan further into the future, a time period can be searched for using the <b>Advance Train Plan</b> tab. Users should be mindful that the further into the future they look, the more likely the plan is subject to change.

<i> Further information can be found here [[Platform Docker Tabs#Advance Train Plan]]. </i>

<b>Note:</b> The <b>Advance Train Plan</b> will be introduced in the 20.09 [[Upgrades]].

Trains that have been diverted to or through the platform docker location will not display on the platform docker unless the platform docker location is added into the schedule as described below.

The platform docker will not be an accurate reflection of platform occupation unless trains that are off-booked route are also rendered.

= Off-booked Route =

The platform docker will only render trains within acumen’s forecast; it will not ‘pick up’ and render platform occupation based on berth stepping alone. Therefore, if a service has been diverted, the schedule needs to be added into acumen’s forecast.

To do this the user should find the relevant headcode either directly via the <b>Global Search</b> tab, or by clicking the approaching train from the track schematic (TD tab) and opening the schedule. 

The user then completes the fields in the <b>Off Route Train Call</b> drop down as shown below.

<b> Note: </b> Even if the intention is for the service to terminate at the platform docker location, a <b>Departure Time</b> different to the <b>Arrival Time</b> should be entered so that an appropriate occupation box can be drawn on the docker.
 
::[[File: off route train.png|600px]]

An off-route schedule will then display on the platform docker. 
For the acumen trial, this is a visual representation only based on the timings entered by the user. This train is not subject to forecast, will not be updated based on TD occupation, and will not cause conflicts.

::[[File: off route render.png|300px]]

= Horizontal and Vertical Views =

The horizontal view provides the benefit of seeing a longer timeframe at a glance. This will be useful if planning ad-hoc moves or infrastructure access and understanding what platforms are forecast to be unoccupied and at what time.  A longer timeframe also means more associations can be seen without having to scroll to see the next working.

To see headcodes clearly in the horizontal view, users can make use of the tool-tip when hovering over the train. Similarly, the <b>Conflict List</b> tab will complement the horizontal view by listing trains in conflict.

The vertical view displays a shorter timeframe at a glance of approximately 25mins. This configuration should still give users enough notice of potential conflicts to resolve them in advance, remembering too the triangular conflict marker that notifies a user of a conflict outside the current view.

The dimensions of the vertical view also allow headcodes, conflicts and other important information to be read clearly without needing to further investigate.