User Cases

User Cases

Understanding Platform Occupation

acumen 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 Planning Layer as described in Section 5.6.

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 in Section 9.2.

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 Global Search 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 Off Route Train Call drop down as shown in Figure 69. Nb. Even if the intention is for the service to terminate at the platform docker location, a Departure Time different to the Arrival Time should be entered so that an appropriate occupation box can be drawn on the docker.

An off-route schedule will display on the platform docker as shown in Figure 70. 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 and will not be updated based on TD occupation.

An off-booked route schedule added to the platform docker will be subject to Occupation Conflicts and Infrastructure Restriction conflicts, but no other types of conflict.

Set Swap

Consider the situation seen in Figure 71. To model a set swap use the Association Editor to form new associations.

Associate 2K33 with 1K08 as shown in Figure 72. 1K08 will automatically move into Platform 1.

Similarly, associate 1K05 with 5H45. 5H45 will automatically move into Platform 3.

For completeness, the planned associations that are no longer rendered but are still listed in the Association Editor (aka the associations seen visually in Figure 71) should be deleted by clicking the [x] as described in Section 8.5.2.

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 as described in 6.1.1. Similarly, the Conflict List 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 (see Section 7.2.2).

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