Editing 21.01 Briefing Note

The sections below detail enhancements that will be deployed to acumen on <b>Sunday 31 January 2021</b>.

Users will need to clear the Chrome Browser cache (hard re-load) in order that the changes made to acumen function correctly. Instructions on how to do this can be found on the [[FAQ]] page.

The relevant [[User Guide]] pages will be updated in due course.-

=Optimisation=
This upgrade includes a number of optimisation works as part of Phase 3 activities in preparation for a national roll-out.

Although not immediately obvious to system users, this optimisation work has benefits such as enabling enhanced message feeds e.g. from DARWIN, and centralising and stabilising the user database.

=New Functionality=

==Station Crossing Conflicts (YORK AND CREWE ONLY)==

<i>Only York and Crewe dockers are configured for this 21.01 upgrade. Work is continuing for the other locations.</i>

Conflicts are now raised against station approach and crossing conflicts; that is where two (or more) routes set conflict outside the station.

The conflict indication is represented as a red <b>(X)</b>.

For example, below we see 1F16 and 1S63 have conflicting routes set.

::[[File:X_example.png|400px]]

A tool-tip is provided that states the trains in conflict and the location, in this example Crewe South Junction.

::[[File:X_tool-tip.png|400px]]

<b>Note:</b> If a crossing conflict has been raised against a service that also has one or more other types of conflict, the red <b>(X)</b> will display, rather than the yellow <b>(C)</b>. A user can still hover over the symbol to see the list of conflicts associated with this train. These will also all be listed within the Conflict List and within the [[Train Details View]].

Station Crossing Conflicts are listed in the <b>Conflict List</b> under the abbreviation <b>SC</b> as seen below.

::[[File:SC_table.png|600px]]

==Data Warning==

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

::[[File:W_example.png|100px]]

<u>User Case</u>

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.

Prior to the 21.01 upgrade, this meant users would see this associated service jumping back and forth between platforms, and raising a split association with red dashed line when these platforms were different.

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

<b>Note:</b> 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 <b>Association Editor</b> to amend the association(s) as required.

<u>Example</u>

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 <b>(W)</b> and logs an item in the <b>Alert List</b> as seen below.

::[[File:W_tool-tip.png|400px]]
::[[File:W_alert.png|1000px]]

<u>User Actions</u>

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

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

::*ANOTHER OPTION TO REPLATFORM INTO THIS PLATFORM?

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

<u><i>Replan Priority</u>

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 </i>

=Enhancements=

==Conflict List Enhancement==

Keeps list more up to date. Disappear off if the train is terminated.

==Alert List Enhancement==

Updates now only listed once. Previously would see repeats in the list.

==Data Feed Behaviour==

==Kings Cross Config?==

=Bug Fixes=

==Association line failed to draw