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 Planning Layer from the Docker Viewing Preferences. For more information see Platform Docker Display#Planning Layer .

To manually call a train, select Manual Call from the context menu. For more information see Context Menu - Replan Functionality#Manual Call (Planned Services Only).

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

Further information can be found here Platform Docker Tabs#Advance Train Plan.

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 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 below.

Note: The option to add an Off Route Train Call is only available for trains that have been called.

Note: 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 then display on the platform docker.

Off route trains have functionality and interactivity similar to other trains in the forecast. This includes applying train notes, applying train running restrictions, creating connections, awaiting train crew, making replan changes, and amending associations.

These trains will also now subject to occupation conflicts and infrastructure restriction conflicts.

Note: Like other trains, off booked route trains will also flag the blue triangular marker if in the TBC column.

The addition to normal forecast trains will be the option on the right-click context menu to cancel the off route call as shown below.

However off route trains are not added into the acumen forecast. The schedule has been provided with the docker location as a calling point but no information as to where it is diverted from, how it reaches the docker location, the line(s) travelled or the journey time. Therefore the forecast occupation will not change based on the train's running.

To mitigate this so that a user does not need to manually keep adjusting the arrival and departure times for this train, the forecast arrival and departure times will be subject to automatic update based on the time the train strikes pre-configured approach berths. (These are the approach berths that prompt the notification alerts in the bottom left hand corner of the docker). For example, in the screenshot above the arrival time has been set to 16:14hrs. If 1D21 strikes the approach berth at 16:00hrs and the time between the approach berth and station has been configured to 10mins, then the platform occupation times for 1D21 will auto-adjust to be arrival at 16:00hrs.

Data Warning

A white (W) will display if the platform shown in acumen is different to that displayed on CIS.

User Case

This occurs most frequently when acumen receives a message from an external system (e.g. DARWIN) about a platform change for a select service.

acumen will enact that platform change and also automatically undertake a platform change for any associated service. This assumes that the same stock will form the associated service.

However, often this associated service has not yet been replanned in the external system and therefore acumen receives messages to try and move it back to its original platform.

To address this, the acumen platform change takes priority (see below) and the associated service will remain in the same platform as the inbound service. The white (W) is displayed in place of the pink (P) to indicate that the platform the service is rendered in on acumen, is different to that shown on CIS. Remember, CIS will display what is entered in DARWIN.

Note: If a service has more than one association and these are showing in different platforms, acumen does not know which to match with and will therefore display a split association. Users should use the Association Editor to amend the association(s) as required.

Example

In this example a platform alteration message has been received from DARWIN advising that 9M50 will terminate in Platform 4 vice Platform 14.

acumen has therefore automatically moved the associated service 1F17 to Platform 4 too.

The platform for 1F17 has not been updated in DARWIN however so DARWIN attempts to move 1F17 back to Platform 14.

acumen prevents this action, displays the white (W) and logs an item in the Alert List as seen below.

Note: Similar to the P icon, a user can right click on the white (W) to copy details about the service onto a clipboard. An example is shown below.

User Actions

The white (W) therefore acts as a prompt to the user with options as follows:

• If the displayed platform represents the operational intent, mentally acknowledge the white (W) but take no action. When a further message is received confirming this associated service in this new platform, the (W) will be replaced by the usual pink (P)

• If the displayed platform does not represent the operation intent (e.g. the outbound service should be in a different platform - maybe achieved by stepping up stock) manually re-platform the service. You may want to remove the association between these trains too.

Data Replan Priority

The order of priority is as follows:

• Manual change within acumen, e.g. click and drag platform change

• Automatic change within acumen, e.g. outbound service has been automatically moved to match the platform of the inbound service

• Change received from outside source, e.g. DARWIN or TIGER

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 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.

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